禁用触发器是最简单有效的绕过方式，因行级触发器在批量导入时逐行执行，导致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 或标量子查询，基本可以判定它不该存在——这些本该由异步队列或应用层统一收口。
