触发器适合自动填充衍生字段和审计日志，但不可用于调用外部接口、跨表强一致性约束或替代应用层校验；mysql 8.0+支持列级判断，需避免死锁、mutating table错误及调试盲区。
触发器适合做数据变更的自动补全和校验
当某张表的字段被插入或更新时，需要同步生成衍生字段（比如 updated_at、status_code），又不想在每个业务代码里重复写逻辑，触发器就比应用层更集中、更难绕过。但要注意：它不能替代应用层校验，因为事务回滚时触发器也会回滚，而有些校验（如检查远程服务状态）根本没法放进去。
- 适用场景：
BEFORE INSERT自动填充created_at和uuid；BEFORE UPDATE强制更新updated_at - 不适用场景：调用外部 HTTP 接口、发消息、写日志文件——这些操作不可回滚，且会拖慢事务
- MySQL 8.0+ 支持
NEW和OLD的列级判断，但不能在触发器里用SELECT ... FOR UPDATE锁其他行，容易死锁
避免用触发器实现跨表强一致性约束
比如“订单表插入时，必须扣减库存表对应商品的 stock_count”，看起来很自然，但实际风险极高。触发器执行在同一个事务内，一旦库存不足导致触发器报错（SIGNAL SQLSTATE '45000'），整个订单插入就失败——这会让业务错误暴露成数据库错误，掩盖了本该由应用处理的业务语义。
- 真正要保一致性的场景，应该用应用层显式事务 +
SELECT ... FOR UPDATE+UPDATE组合 - 如果非要用触发器，只能做弱一致性动作，例如：订单插入后，异步写入一张
inventory_change_log表，再由后台任务消费 - 注意：触发器里不能调用存储函数（
DETERMINISTIC以外的），也不能修改触发它的同一张表（mutating table错误）
审计类日志记录是触发器较稳妥的用途
记录谁、什么时候、对哪条记录做了什么操作，这类需求不参与业务决策，只用于追溯，触发器确实比改所有 DAO 层代码更省事。但得控制粒度，别一更新就全字段记进日志表，否则 I/O 压力大、binlog 膨胀快。
- 推荐做法：只记录关键字段变化，比如
IF OLD.status != NEW.status THEN INSERT INTO audit_log... - 日志表必须加索引，至少是
(table_name, row_id, created_at)，不然查起来慢 - MySQL 5.7 开始支持
JSON_OBJECT()，可以用JSON_OBJECT('old', JSON_OBJECT('status', OLD.status), 'new', JSON_OBJECT('status', NEW.status))存差异，节省空间
触发器调试困难，上线前必须验证异常路径
最常被忽略的是：触发器里的错误不会直接抛给客户端，而是变成一个模糊的 ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger，或者静默失败（尤其在 AFTER 触发器里调用存储过程出错时）。
- 务必在测试库开
general_log = ON，看触发器是否真被执行、执行顺序是否符合预期 - 不要依赖
INSERT INTO error_log VALUES (...)来 debug——它可能因权限或磁盘满而失败，且本身又可能触发新触发器 - 生产环境禁用
SHOW TRIGGERS以外的元数据查询，因为触发器定义存于information_schema.TRIGGERS，高并发下可能成为性能瓶颈
