SQL触发器为何拖慢大量数据导入？

禁用触发器，其实是最简单、也最有效的解决办法。因为行级触发器在面对批量导入时，会逐行执行，导致IO和事务开销被线性甚至指数级放大。更关键的是，MySQL不支持语句级触发器，只能逐行运行，而且没有原生的禁用语法。相比之下，PostgreSQL可以用ALTER TABLE DISABLE TRIGGER ALL，SQL Server可以用DISABLE TRIGGER。

你想想，原本一次性的物理写操作，被硬生生拆成了N次逻辑写、日志写和锁等待，IO和事务开销自然就呈线性甚至指数级放大。

MySQL 触发器：逐行执行，无法绕过

MySQL 5.7/8.0全系列都不支持FOR EACH STATEMENT语法，所有触发器默认且唯一是行级。哪怕一条INSERT INTO t SELECT ... FROM s插入了10万行，AFTER INSERT触发器也会被调用10万次——每次都要初始化上下文、解析SQL、写日志、加锁、等WAL刷盘。

• 别指望靠优化触发器函数内部来解决问题——单次耗时从0.2ms降到0.05ms，总耗时仍然从20秒降到5秒，远不如直接禁用来得干脆。
• 如果BEFORE INSERT里查关联表时，条件字段没索引（比如WHERE email = NEW.email但email无索引），每次插入都触发全表扫描，那性能损失就更夸张了。
• AFTER INSERT中再UPDATE同一张表，甚至可能引发死锁或二次触发，尤其当触发器未设SQL SECURITY DEFINER时，风险更大。

IO瓶颈：卡在WAL和锁等待，不是CPU或磁盘吞吐

批量导入本身就已经在密集地刷WAL了，触发器再额外去更新审计表、日志表，相当于给日志系统叠加了多层写压力。SQL Server中，sys.dm_io_virtual_file_stats显示log_file的io_stall_write_ms会突增10倍以上，而data_file的num_of_writes却无明显变化——这说明瓶颈卡在日志落盘，不是数据文件写不过来。

• 每行触发一次INSERT INTO audit_log，就多一次mini-transaction + WAL记录 + buffer pool刷脏页的机会。
• 在innodb_file_per_table=ON下，频繁的小写入还会加剧.ibd文件碎片，进一步拖慢随机写。
• 触发器内如果包含SELECT COUNT(*) FROM big_table这类语句，innodb_row_lock_time和innodb_buffer_pool_wait_free会同步飙升，整个系统都跟着遭殃。

禁用触发器：比分析执行计划更有效

要验证是不是触发器在拖慢速度，最直接的办法就是临时禁用它，然后重跑一遍相同的导入任务。PostgreSQL用ALTER TABLE t DISABLE TRIGGER ALL，SQL Server用DISABLE TRIGGER tr_name ON t。注意：必须在事务外执行，否则会报错The context in which the current operation is executing does not allow for transaction control。

• 禁用后如果耗时回归正常，基本可以锁定问题；再查sys.triggers（SQL Server）或pg_trigger（PostgreSQL）确认触发器定义，进一步定位原因。
• 禁用期间发生的变更不会触发任何逻辑，失败重试前需要人工补全缺失的副作用（比如漏写的审计日志）。
• MySQL没有原生禁用语法，只能用SET SQL_LOG_BIN = 0（主从场景慎用），或者从应用层想办法绕过。

真正难处理的，其实不是“怎么让触发器快一点”，而是“哪些业务逻辑非得塞进事务的主路径”。一旦发现触发器里有跨库查询、HTTP调用、大表JOIN或标量子查询，基本可以断定它不该存在——这些本该由异步队列或应用层统一收口。