禁用触发器比优化更有效，因其在批量UPDATE中必然逐行执行、无法并行；10万行即10万次调用，轻量逻辑亦致雪崩；应改用生成列、应用层传参及异步统计替代。
直接禁用触发器，比优化它更有效。MySQL 触发器在批量 UPDATE 中必然逐行执行，无法跳过、无法并行——10 万行更新，就是 10 万次触发器调用，再轻的逻辑也会雪崩。
为什么批量 UPDATE 会让触发器变慢到不可接受
这不是配置或写法问题，是 MySQL 的执行机制决定的：哪怕你只写 NEW.updated_at = NOW()，它也会对每一行都调用一次系统时钟函数；如果触发器里有 SELECT、自定义函数或条件判断，单次开销就可能从 0.3ms 拉到 8ms+，10 万行就是 800 秒以上。
-
SHOW PROCESSLIST里大量线程卡在Updating状态 - 慢查询日志中同一条
UPDATE反复出现，每次耗时稳定在几毫秒以上 -
INFORMATION_SCHEMA.PROFILING显示触发器逻辑占总耗时 70%+ - 哪怕加了索引、拆了逻辑、缓存了结果，性能依然无改善——因为瓶颈不在“怎么写”，而在“不该这么用”
禁用触发器后，字段自动填充怎么办
把原本靠触发器赋值的字段（如 updated_at、created_at）改用 MySQL 8.0+ 的生成列，彻底绕过触发器路径：
ALTER TABLE orders ADD COLUMN updated_at DATETIME AS (NOW()) STORED;
- 写入时自动计算，不走任何触发器
- 避免
NOW()在高并发下的时钟争用问题 - 若需时间戳精确到微秒，用
SYSDATE(6)替代NOW() - 注意：生成列不能用于
WHERE条件索引，如需查询，额外建普通列 + 应用层维护
审计类字段（如 created_by）必须由应用层传入
别再依赖 @user_id 或触发器读取 session 变量——这既不可靠又难追踪。显式传参才是可控方案：
INSERT INTO orders (..., created_by) VALUES (..., ?);
- 所有变更来源可审计，不依赖数据库会话上下文
- 避免触发器中隐式调用
USER()或CURRENT_USER()引发权限校验开销 - 如果业务强制要求服务端统一注入，改用应用层中间件拦截 SQL，重写语句补字段
- 切勿在触发器里做
SELECT user_name FROM users WHERE id = @user_id——这是典型全表扫描陷阱
统计类逻辑（如订单数累加）必须移出事务
触发器里更新计数表（如 UPDATE stats SET count = count + 1 WHERE key = 'order_total'）会锁表、放大日志、拖慢主 DML。正确做法是解耦：
- 用
BINLOG解析（Canal / Maxwell）监听变更，异步更新统计 - 或应用层发消息（Kafka / RabbitMQ），由独立消费者聚合后写库
- 临时应急可用
INSERT INTO log_table (event_type, target_id) VALUES ('order_created', ?)记原始事件，后台定时批处理 - 绝对不要在触发器里写
INSERT INTO big_audit_log——千万级日志表没分区+没索引，每次插入都是全表扫描
真正难的不是让触发器跑得更快，而是判断「这件事到底该不该放触发器里做」。只要涉及批量、跨表、IO、函数调用或任何不确定性操作，它就已经越界了。
