不该直接删掉触发器。其性能问题多源于内部复杂SQL（如大表查询、跨表写入），而非触发器本身；简单赋值开销可忽略，应通过慢日志和EXPLAIN定位瓶颈，并优化逻辑、区分BEFORE/AFTER时机、减少数量及移出非核心操作。
触发器执行慢，是不是该直接删掉？
多数情况下不是。触发器本身不必然拖慢性能，真正吃资源的是它内部的 SELECT、UPDATE 或跨表写操作——尤其是对大表做 INSERT ... SELECT 或在 BEFORE 触发器里调用复杂函数。如果触发器只做简单字段赋值（如 NEW.updated_at = NOW()），开销几乎可忽略。
判断依据看 SHOW PROFILES 或慢日志中是否出现 Trigger 关键字，再结合 EXPLAIN 检查触发器内 SQL 的执行计划。
避免在触发器里查大表或写大表
这是最常见也是最致命的误用：比如在订单表 orders 的 AFTER INSERT 触发器里，去统计用户最近 1000 条订单并更新 users 表的 total_spent 字段。每次插入都触发全量扫描，QPS 上去就卡死。
- 改用异步方式：把统计逻辑移到应用层或消息队列，由后台任务批量处理
- 若必须同步，改用覆盖式更新：只查
WHERE user_id = NEW.user_id AND created_at > DATE_SUB(NOW(), INTERVAL 1 DAY)，加好索引 - 禁止在触发器中调用存储过程，除非该过程已明确压测过并发表现
区分 BEFORE 和 AFTER 触发时机的代价
BEFORE 触发器在语句执行前运行，能修改 NEW 值，但若里面包含 SELECT ... FOR UPDATE 或锁行操作，会延长事务持有锁的时间；AFTER 触发器不阻塞主语句，但无法修改当前行数据，且一旦失败会导致整个事务回滚（MySQL 5.7+ 默认行为）。
实操建议：
- 仅需审计或记录日志 → 用
AFTER，降低锁竞争 - 需校验/修正插入值（如标准化手机号格式）→ 用
BEFORE，但避免任何SELECT查询 - 涉及多表写入 → 优先
AFTER，并在触发器开头加IF NOT EXISTS (SELECT 1 FROM ...)防重复写入
触发器太多导致元数据锁争用
MySQL 在执行 DML 前要加载所有相关触发器定义，触发器数量超过几十个时，尤其在高并发 INSERT 场景下，metadata lock 等待会明显上升。可通过 SELECT COUNT(*) FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA = 'your_db' 快速统计。
减负策略：
- 合并功能重叠的触发器（例如多个都更新
updated_at，统一成一个） - 把非强一致性逻辑（如埋点计数、缓存失效）移出触发器，改用应用层双写或 Canal 监听 binlog
- 开发环境保留，生产环境按需禁用：
ALTER TABLE t1 DISABLE TRIGGER tr_name（MySQL 8.0.19+ 支持）
触发器不是黑盒，它的执行路径完全暴露在 slow log 和 performance_schema 中。真正难调的从来不是语法，而是你没意识到某条 UPDATE 正在给整张订单表加表级锁。
