触发器性能瓶颈源于同步执行、逐行调用及主事务内阻塞；优化核心是减少其工作量并避免主线程卡顿：before仅做确定性赋值与校验，禁查表或加锁；after禁更新同表以防死锁；推荐用极简中转表+外部消费者解耦；须通过慢日志、explain和元数据统计精准定位真实开销。
触发器本身不拖慢事务，拖慢的是它里面干的活——尤其是同步执行、逐行调用、还卡在主事务里。优化目标不是“让触发器跑更快”，而是“让它少干点、别卡主线程”。
BEFORE触发器里只做确定性赋值和校验
BEFORE时机适合修正数据，但必须守住边界：它在语句执行前介入，一旦加锁或查表，就会延长主事务持锁时间。
- 允许：
SET NEW.created_at = NOW()（需确认binlog_format = ROW）、SET NEW.phone = REPLACE(NEW.phone, '-', '')、空值校验后SIGNAL报错 - 禁止：
SELECT ... FOR UPDATE、查用户等级表、调用含SELECT的自定义函数、生成UUID()或RAND() - 注意：
NOW()在复制环境下非确定，若主从不一致风险高，改用应用层传入时间戳
AFTER触发器禁止更新同表或强依赖行锁
AFTER看似“事后再处理”，实际仍处于同一事务中，且MySQL 8.0+对锁行为更严格——它可能同时持有新插入行的X锁和你要UPDATE的目标行锁，极易死锁。
- 典型错误：
AFTER INSERT ON orders→UPDATE order_summary SET total = total + NEW.amount - 安全做法：把这类聚合逻辑移出触发器，改由应用层异步任务或定时JOB批量更新
- 若必须同步记录日志，只写极简中转表：
INSERT INTO trigger_queue (id, table_name, event_type) VALUES (NEW.id, 'orders', 'insert')，字段越少越好，禁用二级索引
用中转表+外部消费者替代同步处理
中转表不是缓存，是解耦开关。它的价值不在“存”，而在“快进快出”——主事务只做一次轻量INSERT，后续全由外部进程接管。
- 中转表结构必须极简：
id BIGINT、table_name VARCHAR(64)、event_type ENUM('insert','update','delete')、created_at DATETIME，引擎用InnoDB - 消费者拉取逻辑不能
SELECT ... LIMIT N再DELETE：失败会丢数据，重试会重复处理 - 正确姿势：
UPDATE trigger_queue SET status = 'processing' WHERE status = 'pending' ORDER BY created_at LIMIT 100→SELECT这批已标记的 → 处理成功后DELETE或UPDATE status = 'done'
监控触发器真实开销而非假设
MySQL不暴露触发器单独耗时，靠猜没用。必须用组合手段定位瓶颈：
- 开启
slow_query_log并设long_query_time = 0，抓全量慢日志，搜索Trigger关键字 - 对慢SQL执行
EXPLAIN FORMAT=TREE，看执行计划是否含子节点调用触发器逻辑 - 查
information_schema.TRIGGERS确认数量：SELECT COUNT(*) FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA = 'your_db'，超20个就该合并或清理 - 高频表上触发器越多，元数据锁争用越明显，
SHOW PROCESSLIST常看到Waiting for table metadata lock
最易被忽略的一点：很多所谓“触发器性能问题”，其实是应用层本可提前完成的数据准备（比如折扣规则、用户状态）被硬塞进了触发器里实时查——这根本不是数据库该干的活。
