首先给出一项关键结论：如果你在MySQL 8.0环境中，正对一张数据量庞大的表执行批量UPDATE操作，而这张表上恰好绑定了触发器——哪怕触发器内部仅包含一行代码——数据库性能急剧下降几乎是必然的结果。这并非是你的代码逻辑出现了错误，而是MySQL触发器本质上就不适合处理批量数据场景。

触发器在批量UPDATE操作中会逐行调用，导致性能瓶颈难以避免

用一个最常见的例子来说明：UPDATE t SET x = 1 WHERE id IN (1,2,3,...,10000)。这条SQL语句看起来是一条命令，但MySQL并不会“整体触发一次”触发器，而是对每一行数据单独执行一遍触发器逻辑。即使触发器内容仅仅是简单的NEW.updated_at = NOW()，它也会被重复执行10000次——并且是串行执行、不可跳过、无法并行处理的。

你可能会在SHOW PROCESSLIST输出中观察到大量线程卡在Updating状态；在慢查询日志里，同一条UPDATE语句反复出现，且每次执行耗时稳定在数毫秒以上；通过INFORMATION_SCHEMA.PROFILING深入分析后会发现，触发器逻辑竟然占据了总耗时的70%以上。

还有一个容易被忽视的细节：NOW()函数在高并发环境下，会因系统时钟函数争用而产生微小的延迟。这种延迟单独每次看几乎可以忽略不计，但累积到10000次时，其影响就不可小觑了。更值得警惕的是，如果触发器内部还包含了一个SELECT语句或带有READS SQL DATA属性的自定义函数，单次执行的开销可能从0.3毫秒直接飙升到8毫秒以上——对于10000行数据而言，总耗时将高达80秒。

禁用触发器往往比优化它更有效

许多团队在遇到这一问题时，第一反应是为触发器添加索引、拆分逻辑或缓存查询结果。但方向其实错了。问题的根源不在于触发器写得不够高效，而在于它根本不应该承担批量场景下的逻辑分发职责。MySQL触发器的设计定位是“轻量、确定、单行响应”，而不是充当“业务协调中枢”。

真正有效的解决方式是让SQL语句本身绕开触发器的执行路径。下面几项策略值得你记录下来：

• 使用INSERT ... ON DUPLICATE KEY UPDATE语句来替代普通的UPDATE。先将目标数据写入临时表，再通过这一语法完成更新，整个过程不会触发任何触发器。
• 将诸如updated_at这类自动填充字段改为生成列：updated_at DATETIME AS (NOW()) STORED（MySQL 8.0及以上版本支持），写入数据时自动计算值，且完全不走触发器。
• 审计字段如created_by必须由应用层显式传入参数，不要依赖@user_id或触发器读取会话变量。
• 统计类更新操作（例如订单数量累加）一并移出数据库，改用BINLOG解析工具（如Canal、Maxwell）或应用层异步任务处理。

这些方案从根本上绕开了触发器，性能提升的效果立竿见影。

必须保留触发器时，仅允许纯计算的BEFORE触发器

如果由于严格的审计要求（例如金融系统）而无法移除触发器，就将其压缩到仅保留最基础的功能：

• 只支持BEFORE INSERT和BEFORE UPDATE触发器，禁用所有AFTER类型的触发器。
• 触发器内部禁止执行任何SELECT、UPDATE、INSERT、DELETE语句。
• 禁止调用任何带有READS SQL DATA或MODIFIES SQL DATA属性的自定义函数。
• 字段赋值仅限使用确定性表达式，例如NEW.ts = UNIX_TIMESTAMP()，避免使用NOW()。
• 禁止使用IF/CASE分支以外的逻辑结构，如循环、异常捕获等。

还有一点需要特别留意：即使你采用了LIMIT分批执行UPDATE，只要表上存在触发器，每一批中的每一行数据仍然会触发一次触发器——批次越小，上下文切换带来的开销反而越重。因此，分批操作并不能真正解决问题，只是将压力分散开来而已。

不要指望用EXPLAIN来发现触发器耗时

EXPLAIN FORMAT=TREE仅展示DML语句本身的执行计划，而触发器是在语句执行完毕后，由存储引擎层同步调用的“事后动作”，因此不参与代价模型的计算。这意味着：

• 你无法通过EXPLAIN预估触发器带来的额外耗时，只能依赖performance_schema.events_statements_history_long来查询具体的执行时间。
• MySQL 8.0版本默认开启了events_statements_history_long，其数据采集开销甚至比5.7版本更高。在执行测试之前，务必先运行：UPDATE performance_schema.setup_consumers SET ENABLED = 'NO' WHERE NAME LIKE 'events_statements_%';来关闭不必要的采集功能。
• 升级到8.0后，元数据加载速度确实更快（得益于事务性数据字典），但如果你没有关闭性能采集功能，实际表现可能会更慢。

最后再强调一点：真正限制你数据库性能的，往往不是某一行代码写错了，而是你默认接受了“触发器就应该这样用”这个前提——而在批量场景下，它从来就不该被启用。