mysql触发器禁止直接update被修改的表，因引擎层硬性限制；需用外键级联、应用层协调或改由关联表触发器实现；须防null与类型隐式转换；禁用子查询及多行性能陷阱；alter table后需手动重写触发器。
MySQL触发器不能直接UPDATE被修改的表
你写完 BEFORE UPDATE 触发器，里面又对同一张表执行 UPDATE，MySQL 会报错：Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger. 这不是语法写错了，是引擎层硬性限制。
常见错误场景：想在 orders 表更新时，自动同步更新 order_items 表里关联的 status 字段，结果在 orders 的触发器里直接写 UPDATE order_items SET ... —— 必炸。
- 必须改用应用层或存储过程协调，触发器只负责“通知”或“记录”，不负责跨表写操作
- 如果真要级联更新，优先考虑外键
ON UPDATE CASCADE（仅限 InnoDB + 带索引的外键列） - 实在要用触发器驱动，得把目标表更新逻辑移到另一个表的触发器里（比如在
order_items上建触发器，监听orders状态变更的标志字段）
触发器里读取 NEW/OLD 值要防 NULL 和类型隐式转换
NEW.status 看似简单，但实际运行中容易踩两个坑：一是字段允许 NULL，你没判空就拼进字符串或算术表达式，结果整个语句返回 NULL；二是 NEW.id 是 BIGINT，你在触发器里跟字符串拼接（比如日志），MySQL 会静默转成科学计数法或截断。
典型表现：触发器看似执行成功，但下游更新条件失效、日志记录错乱、时间字段变成 0000-00-00。
- 所有涉及
NEW.xxx或OLD.xxx的比较、拼接、计算，先用IFNULL()或COALESCE()处理空值 - 拼接字符串时显式转类型：
CONCAT('id=', CAST(NEW.id AS CHAR))，别依赖自动转换 - 时间字段参与比较前，用
IFNULL(NEW.updated_at, NOW())避免 NULL 传播
触发器性能瓶颈常出现在子查询和多行影响场景
一个 UPDATE orders SET status = 'shipped' WHERE user_id IN (1,2,3) 可能一次影响几百行，但你的 BEFORE UPDATE 触发器里写了 SELECT COUNT(*) FROM order_items WHERE order_id = NEW.id —— 这个子查询就会被执行几百次，IO 和锁开销陡增。
更隐蔽的问题是：触发器里调用自定义函数，而该函数内部又查表，等于嵌套查询，极易拖垮并发更新。
- 禁止在触发器中写依赖外部表的子查询，尤其不能查正在被批量更新的主表关联表
- 如需统计类数据，提前在业务层算好，通过额外字段传入（比如
UPDATE ... SET status = 'shipped', item_count = 5） - 触发器体内容越短越好，只做必要字段修正、状态标记、日志插入，别塞业务逻辑
ALTER TABLE 后触发器不会自动适配新字段
你给 orders 表加了个 sync_flag TINYINT DEFAULT 0，然后在触发器里直接写 SET NEW.sync_flag = 1，结果报错：Unknown column 'sync_flag' in 'NEW'。触发器定义固化在创建时刻，不会随表结构变更自动更新。
这个坑往往在线上加字段后才发现——老触发器跑着跑着突然挂了，而且错误日志不明显，只显示触发器执行失败。
- 每次
ALTER TABLE涉及字段增删改，必须人工检查并重写对应触发器（DROP TRIGGER+CREATE TRIGGER） - 避免在触发器里引用非必需字段，优先用已存在且稳定的字段做判断依据
- 上线前用
SHOW CREATE TRIGGER trigger_name对比确认字段列表是否匹配当前表结构
触发器不是“设好就不用管”的自动化开关，它对表结构变化极度敏感，每次 DDL 都得手动过一遍依赖链。这点比外键或应用层逻辑更难维护。
