新项目里直接写 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+ 版本会报错
真正难的不是写出来，而是后续改——一旦函数被上百个查询引用，改一个参数类型就得全链路排查。不如一开始就把逻辑留在应用里，数据库只管存和查。
