新项目不推荐大量使用MySQL自定义函数和触发器。函数受限多、易致索引失效、升级兼容性差；触发器隐式执行、调试难、主从不一致风险高；优先用应用层封装、视图或存储过程替代。
新项目里直接写 MySQL 函数容易踩哪些坑
不推荐在新项目中大量使用 MySQL 自定义函数（CREATE FUNCTION），尤其当业务逻辑涉及事务控制、外部服务调用或复杂数据校验时。MySQL 函数限制极多：NO SQL、READS SQL DATA 之外的函数不能在查询中调用；不能修改表、不能显式开启事务、不能调用存储过程；错误处理能力弱，GET DIAGNOSTICS 支持有限。
常见翻车场景包括：
- 想在
SELECT中调用函数做权限判断，结果因函数含INSERT被拒绝 - 函数内拼接 JSON 后返回，但 MySQL 5.7 对
JSON_OBJECT的字段名强制要求是常量，无法动态传参 - 函数被用于
WHERE条件，导致索引失效（如WHERE my_func(status) = 1） - 升级到 MySQL 8.0 后，原
DETERMINISTIC声明的函数因实际非确定性被拒绝创建
触发器在新项目中该不该启用
触发器（CREATE TRIGGER）比函数更危险——它隐式执行、调试困难、事务上下文紧耦合，且无法被 ORM 或应用层感知。新项目除非满足全部下述条件，否则建议绕开：
- 操作必须 100% 在数据库侧原子完成（例如：某张日志表必须在主表
INSERT同一事务中生成快照） - 没有跨库/跨表强一致性要求（触发器不能跨实例生效）
- 团队具备
INFORMATION_SCHEMA.TRIGGERS监控和SHOW CREATE TRIGGER快速定位能力 - 已禁用
sql_log_bin=OFF场景（否则主从不一致）
典型反例：用触发器自动更新统计表，结果批量导入时触发器逐行执行拖慢导入速度，且出错后难以回滚单条记录。
