新项目不推荐大量使用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场景（否则主从不一致）
典型反例：用触发器自动更新统计表，结果批量导入时触发器逐行执行拖慢导入速度，且出错后难以回滚单条记录。
替代方案：什么情况下值得用，怎么用更稳
如果确实需要复用逻辑，优先级顺序应为：应用层封装 > 视图（VIEW） > 存储过程（PROCEDURE） > 函数/触发器。其中：
- 视图适合封装查询逻辑（如
CREATE VIEW user_active AS SELECT ... WHERE status = 1），可被索引优化，无执行副作用 - 存储过程适合明确边界的操作（如“创建订单并扣减库存”），支持事务控制、异常捕获（
DECLARE HANDLER）、参数校验，且调用意图清晰（CALL create_order(...)） - 若坚持用函数，仅限纯计算场景（如
date_diff_in_workdays()），且必须声明DETERMINISTIC+READS SQL DATA，避免任何INSERT/UPDATE/DELETE
MySQL 8.0+ 落地要注意的硬约束
新版 MySQL 对函数和触发器的权限、安全模型收紧明显，上线前必须验证：
- 用户需有
CREATE ROUTINE+EXECUTE权限，且log_bin_trust_function_creators默认为OFF（开启需 SUPER 权限，生产环境通常禁用） - 触发器中的
AFTER INSERT无法读取新插入行的自增 ID（除非用LAST_INSERT_ID()，但并发下不可靠） - 函数内调用
NOW()/CURRENT_TIMESTAMP在复制环境中可能主从不一致（建议用SYSDATE()并确认 binlog_format=ROW） - 所有函数/触发器定义必须显式指定
SQL SECURITY（DEFINER或INVOKER），否则 8.0.16+ 版本会报错
真正难的不是写出来，而是后续改——一旦函数被上百个查询引用，改一个参数类型就得全链路排查。不如一开始就把逻辑留在应用里，数据库只管存和查。
