不适合。mysql触发器对新手高风险：行为隐蔽、调试困难、易引发连锁副作用；执行时机不可见，错误提示模糊；无法事务回滚控制副作用；性能瓶颈明显；替代方案如应用层钩子更可控可靠。
MySQL 不建议在新项目中默认启用触发器，核心原因就两条：调试不可见、性能不可控。它不是“不能用”，而是“一旦用了，出问题时你既看不到它在哪卡住，也很难证明它拖慢了谁”。
触发器为什么根本没法调试
MySQL 没有触发器断点、不支持单步执行、也不能在运行时打印变量值——SELECT 会中断流程，SIGNAL 会报错回滚，唯一可行的“调试”就是往日志表里硬塞记录。
- 所有触发器逻辑都隐式嵌入 DML 语句中，
SHOW PROCESSLIST只显示Update或Insert，不会标出“正在执行 user_updated_at_trigger” -
EXPLAIN对INSERT INTO users完全不展示触发器路径，哪怕它内部执行了 5 条 SQL - 想查某次更新为什么慢？得先确认目标表有没有触发器：
SELECT * FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'users'，再人工翻定义，再加日志表，再重放——整个链路无法自动化 - 多个触发器叠加（比如
BEFORE UPDATE改字段 +AFTER UPDATE写日志）时，执行顺序固定但错误传播路径模糊，ERROR 1422这类报错只说“不允许提交”，不指明是哪个触发器干的
触发器让性能衰减变得隐蔽且非线性
它不像慢查询那样能直接定位到某条 SQL；它的耗时被合并进主语句里，而主语句本身可能完全合规——INSERT INTO orders 很快，但加上触发器后就卡住，你却看不出哪部分在拖。
- 单条
INSERT增加 0.8ms 是常态，但批量插入 1000 行时，这个 0.8ms 就变成 800ms，且无法通过索引优化缓解 -
BEFORE INSERT中调用SELECT COUNT(*) FROM config，每次插入都查一次配置表，等于把 O(1) 操作放大成 O(n) -
AFTER UPDATE里写日志表，如果日志表没主键或没索引，INSERT会退化为全表扫描式写入，QPS 在 64 并发时直接腰斩 - performance_schema 的
events_statements_history_long能抓到触发器内的语句，但字段SQL_TEXT是截断的，长逻辑看不全，还得靠人工拼接
替代方案比“优化触发器”更实际
多数所谓“必须用触发器”的场景，其实只是没把逻辑推到更合适的位置。真要保强一致，应用层事务比触发器更可控；真要审计，binlog 解析比日志表更轻量。
- 字段自动补全（如
full_name）→ 改用GENERATED ALWAYS AS (CONCAT(first, ' ', last)) STORED，零运行时开销 - 操作日志 → 应用层在同一个事务里
INSERT INTO users+INSERT INTO audit_log，可批量合并、可重试、可监控延迟 - 跨表状态同步（如订单创建后扣库存）→ 改用消息队列异步通知，或 Canal 监听 binlog 后处理，彻底解耦写入路径
- 强一致性校验（如余额不能为负）→ 改用
CHECK约束（MySQL 8.0.16+），失败直接报错，不进触发器逻辑
最麻烦的从来不是“触发器多慢”，而是“你发现它慢了，却没法在不改业务逻辑的前提下把它摘出来单独压测”。它像数据库里的影子进程，存在感弱，但只要一动，整条写入链路就跟着抖。
