mysql触发器必然逐行执行，因其仅支持for each row行级触发，不支持语句级；大表update影响n行即触发n次，带来上下文初始化、锁、日志等线性叠加开销。

大表UPDATE触发器为什么必然逐行执行

MySQL 不支持语句级触发器（FOR EACH STATEMENT），所有触发器默认且唯一是行级（FOR EACH ROW）。哪怕执行 UPDATE t SET status = 'done' WHERE id BETWEEN 100000 AND 200000 这样一条语句，只要影响 10 万行，AFTER UPDATE 触发器就会被调用 10 万次——每次都要初始化 NEW/OLD 上下文、解析子查询、加行锁、写 binlog/WAL、刷脏页。这不是“慢一点”，而是把一次逻辑操作硬拆成 10 万次事务内同步调用。

禁用后吞吐量提升的本质是绕过 N 倍开销

触发器带来的不是固定延迟，而是随行数线性甚至指数放大的叠加成本：

• INSERT INTO audit_log 每行一次 → 产生 10 万次 mini-transaction + WAL 记录
• SELECT COUNT(*) FROM orders WHERE user_id = NEW.user_id 每行一次 → 若没索引，就是 10 万次全表扫描
• json_extract(NEW.payload, '$.meta') 每行一次 → 每次都完整解析 JSON 字符串，无法复用执行计划
• 系统时钟函数如 NOW() 在高并发下争用内核时钟锁，单次延迟从 0.3ms 累积到 5ms+，10 万行就是 500 秒

禁用后，这些开销直接归零；原 UPDATE 语句退回到纯数据页修改路径，InnoDB 可批量刷脏页、合并日志、跳过锁等待链。

不同数据库禁用触发器的实操要点

禁用不是删除，必须用原生机制并验证生效：

• SQL Server：DISABLE TRIGGER [trg_log] ON [dbo].[big_table]，执行后查 sys.triggers.is_disabled 确认为 1
• PostgreSQL（12+）：ALTER TABLE big_table DISABLE TRIGGER trg_sync，注意需在 BEGIN; ... COMMIT; 内执行，否则不生效
• MySQL（8.0.23+）：ALTER TABLE big_table DISABLE TRIGGER big_table_after_update；老版本只能用 RENAME TRIGGER 临时改名，且必须带数据库前缀（如 mydb.big_table_after_update）

别信 SET sql_log_bin = 0 或 sql_mode 修改——它们完全不影响触发器执行。

禁用后最常被忽略的三件事

禁用只是跳过实时逻辑，不代表可以丢掉业务语义：

• 手动补执行关键副作用：比如触发器里本该更新 user_summary.total_orders，现在要用 UPDATE user_summary s JOIN (SELECT user_id, COUNT(*) c FROM big_table WHERE updated_at >= '2026-09-02' GROUP BY user_id) t ON s.id = t.user_id SET s.total_orders = s.total_orders + t.c 一次性完成
• 检查并修复审计断层：确认 audit_log 表是否缺失对应时间段记录，必要时从 binlog 或源数据重放
• 验证约束完整性：有些触发器承担了外键或 CHECK 替代职责，需额外运行 SELECT COUNT(*) FROM big_table WHERE status NOT IN ('pending','done') 类校验

漏掉任何一项，问题不会立刻暴露，但下游报表、对账或风控模块可能在几天后产出错误结果——这种延迟性才是最危险的。