校验逻辑必须放在 before insert 或 before update 中；after 仅适用于日志记录等不干预主流程的操作，因数据已落库，校验失效且无法阻止脏数据短暂可见。
触发器里用 AFTER INSERT 还是 BEFORE INSERT？
校验逻辑必须放在 BEFORE INSERT 或 BEFORE UPDATE 里。如果写成 AFTER，数据已经落库，再抛错只会回滚事务但无法阻止脏数据短暂存在——尤其在高并发下可能被其他会话读到（即使隔离级别高，AFTER 的校验也失去意义）。
-
BEFORE触发器中可直接修改NEW字段（比如标准化手机号、补默认值），也能用SIGNAL SQLSTATE '45000'主动报错中断插入 -
AFTER只适合做日志记录、异步通知等不干预主流程的操作，不能用于完整性兜底 - MySQL 8.0+ 支持
BEFORE DELETE做级联校验（比如检查子表是否为空），但老版本只能靠应用层或外键约束
SIGNAL SQLSTATE 报错时为什么总提示 Unknown error？
MySQL 对 SIGNAL 的错误信息长度有限制（最大64字符），且不支持变量拼接。直接写 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = CONCAT('金额不能为负:', NEW.amount) 会静默失败，最终只报泛泛的 Unknown error。
- 必须用字面量字符串：
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '金额不能为负'; - 如需动态内容，先用
IF判断再分路SIGNAL，例如：IF NEW.amount - 避免在触发器里调用存储函数返回错误信息——函数执行失败会导致整个触发器中断，且错误不可控
触发器访问其他表导致性能崩了怎么办？
在 BEFORE INSERT 里写 SELECT ... FROM orders WHERE user_id = NEW.user_id 是典型陷阱：每插一条就查一次，批量导入时变成 N+1 查询，锁表风险陡增。
- 优先用外键约束替代简单引用校验（比如
user_id必须存在users表），外键由引擎原生优化，无额外开销 - 真要跨表查，请确认目标表有合适索引（不只是主键），且查询条件能走索引；否则加
EXPLAIN看执行计划 - 禁止在触发器里做
UPDATE或INSERT操作（除非明确知道不会递归触发），否则极易死锁或无限循环
时间类字段自动填充为什么在触发器里失效？
用 NEW.created_at := NOW() 在某些 MySQL 版本（尤其是 5.7 严格模式下）会报错，因为 NOW() 是非确定性函数，而触发器对赋值表达式有隐式限制。
- 改用
NEW.created_at := CURRENT_TIMESTAMP;—— 这是标准语法，兼容性更好 - 如果字段定义为
created_at DATETIME DEFAULT CURRENT_TIMESTAMP，其实根本不用触发器，直接删掉相关逻辑更安全 - 注意时区：
CURRENT_TIMESTAMP返回服务器时区时间，若应用跑在 UTC，而数据库设为SYSTEM，可能造成时间偏差
触发器不是万能胶，它藏在数据库深处，一旦出问题很难追踪。最麻烦的是多触发器叠加、或和外键/级联操作耦合时，错误堆栈里根本看不到真实源头。上线前务必用真实数据量压测，别只在空表上验证逻辑。
