MySQL触发器禁止修改触发它的表，BEFORE中可安全赋值NEW字段，AFTER中NEW.id才可用；避免复杂查询和函数调用，注意8.0严格模式兼容性。
触发器里改同一张表会报错 ERROR 1442
MySQL 不允许在触发器中对触发它的那张表执行 INSERT、UPDATE 或 DELETE。比如在 orders 表的 BEFORE UPDATE 触发器里再写 UPDATE orders SET ...，直接报错：ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.
常见于想“自动修正字段值”的场景，比如更新订单状态时顺手算出应付金额——但金额字段也在 orders 表里，不能直接 SET NEW.amount = ... 吗？可以，但仅限于 BEFORE 触发器中的 NEW 赋值；如果是想查其他行再更新当前行，就绕不开这个限制。
- 用
BEFORE INSERT/UPDATE直接修改NEW.xxx字段，这是安全的 - 需要跨行计算（比如统计用户总订单数）？改用应用层或定时任务，别硬塞进触发器
- 真要强依赖数据库侧逻辑，考虑用视图 + 生成列（MySQL 5.7+），或把衍生数据拆到独立汇总表
AFTER INSERT 里不能读取 NEW 的自增 ID 吗？
能读，但有个关键前提：必须是 AFTER INSERT，不是 BEFORE。因为自增 ID 在 BEFORE 阶段还没生成，NEW.id 是 NULL；到了 AFTER 阶段，它才真实可用。
典型误用是想在插入后立刻往关联表写记录，结果用了 BEFORE，导致外键字段写入 NULL 或默认值，后续查不到关联数据。
- 写日志、发通知、插入子表这类操作，一律用
AFTER INSERT -
NEW.id在AFTER中是确定值，可放心用于INSERT INTO order_items (order_id, ...) - 如果主键不是自增而是 UUID，
BEFORE就能用NEW.id，但要注意避免重复生成逻辑
触发器里调用函数影响性能吗？
影响，而且可能比你想象得更直接。触发器是同步执行的，每一条 DML 都会卡住等触发器跑完。如果里面调用了含复杂查询、循环或外部服务的存储函数，写入延迟会明显上升，高并发下容易堆积。
比如一个 BEFORE UPDATE 触发器里执行 SELECT COUNT(*) FROM huge_log_table WHERE user_id = NEW.user_id，单条更新就可能从几毫秒变成几百毫秒。
- 触发器内只做轻量级逻辑：字段赋值、简单条件判断、拼接字符串
- 避免
SELECT查询（尤其是没索引的）、游标、循环、调用其他存储过程 - 如果业务必须查数据，优先考虑冗余字段 + 应用层维护，或者用异步消息解耦
MySQL 8.0 的触发器和老版本有啥兼容性坑？
最大的变化是：MySQL 8.0 默认开启 sql_mode 中的 STRICT_TRANS_TABLES，而老版本常是宽松模式。这会让原本“悄悄失败”的触发器逻辑直接报错中断。
比如触发器里写了 SET NEW.phone = SUBSTR(NEW.phone, 1, 11)，但 phone 是 VARCHAR(10)，老版本会截断存入，8.0 则抛出 ERROR 1265 (01000): Data truncated for column 'phone' 并回滚整条语句。
- 上线前务必在目标 MySQL 版本上测试触发器，重点看字段长度、数值溢出、空值插入等边界
- 建表时显式定义
NOT NULL DEFAULT ''或DEFAULT NULL，别依赖隐式行为 - 用
SHOW VARIABLES LIKE 'sql_mode';核对环境，开发和生产保持一致
触发器看着省事，但一旦嵌套、跨表、带查询，问题就藏在执行路径最深的地方——不是不能用，是得清楚哪一行代码会在哪一秒让整个事务卡住。
