INSERT触发器在行级写入前/后执行：BEFORE INSERT可修改NEW值但不能读未赋值的自增ID，AFTER INSERT才可安全访问生成主键；ON DUPLICATE KEY UPDATE时BEFORE INSERT仍触发，冲突则转为UPDATE触发器。
INSERT 触发器在什么时机真正执行？
MySQL 的 BEFORE INSERT 和 AFTER INSERT 触发器不是在语句解析后立刻运行，而是在行级写入前/后触发——这意味着：
-
BEFORE INSERT可修改NEW值（如自动填充created_at、校验字段非空），但不能读取NEW.id（若为自增且未显式赋值） -
AFTER INSERT才能安全访问生成的主键值（如NEW.id），也才能对其他表做关联插入 - 若使用
INSERT ... ON DUPLICATE KEY UPDATE，BEFORE INSERT仍会触发，但冲突时不会走AFTER INSERT，而是可能触发BEFORE UPDATE/AFTER UPDATE（取决于是否更新）
常见错误：在 BEFORE INSERT 中尝试 SELECT ... FROM same_table 会报错 Can't update table 't' in stored function/trigger，这是 MySQL 的限制，不是权限问题。
UPDATE 触发器如何判断字段是否“真被修改”？
MySQL 触发器不自动识别语义上的变更。哪怕写 UPDATE t SET status = status，只要语法合法，BEFORE UPDATE 和 AFTER UPDATE 都会执行。
- 判断某字段是否变化，必须显式比较：
IF OLD.status != NEW.status THEN ... - 注意 NULL 比较：
OLD.col = NEW.col在任一为 NULL 时结果为 NULL（即 false），应改用NOT (OLD.col NEW.col) - 多字段批量更新时，每个字段都要单独判断；没写进 SET 子句的字段，
NEW.col等于OLD.col，但不会被自动跳过
性能影响：触发器中执行复杂查询或调用函数（尤其是涉及大表 JOIN 或子查询）会显著拖慢 UPDATE 速度，且无法被索引优化绕过。
DELETE 触发器无法阻止级联删除的陷阱
BEFORE DELETE 触发器可以抛出异常（如 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Forbidden'）来中止单行删除，但以下情况它无能为力：
