SQL触发器在批量插入时性能必然变慢，因其强制行级执行、无法合并或并行；有效应对只有禁用或绕开，而非优化。
SQL触发器在批量插入时性能必然变慢，这不是配置或写法问题，而是数据库执行机制决定的——它必须为每一行单独执行一次，无法跳过、无法合并、无法并行。所谓“优化触发器”是伪命题，真正有效的动作只有两个：禁用，或彻底绕开。
为什么批量 INSERT 会让触发器耗时线性甚至指数级增长
MySQL 和 SQL Server 都不支持语句级触发器（FOR EACH STATEMENT），所有触发器默认且唯一是行级（FOR EACH ROW）。这意味着：
- INSERT INTO t VALUES (1),(2),(3) 插入 3 行 → 触发器执行 3 次
- BULK INSERT 50 万行 → 触发器逻辑被调用 50 万次，哪怕只有一行
NEW.updated_at = NOW() - 每次调用都要初始化 NEW 上下文、解析表达式、写日志、加锁、等待 WAL 刷盘——单行延迟从 0.2ms 变成 5ms，总耗时就是 2500 秒
- 触发器内任何
SELECT（如查用户配置）都会变成 N 次全表扫描；JOIN或子查询直接让单次开销翻 10 倍以上
如何快速验证是否是触发器导致变慢
别猜，直接关掉对比。不同数据库禁用方式不同，但原理一致：脱离触发器路径后，耗时应明显回落。
- SQL Server：
DISABLE TRIGGER tr_name ON table_name，再跑相同BULK INSERT，观察sys.dm_io_virtual_file_stats中 log_file 的io_stall_write_ms是否骤降 - PostgreSQL：
ALTER TABLE t DISABLE TRIGGER ALL（注意不能在事务内执行） - MySQL：不支持原生禁用，可用临时开关变量模拟，如在触发器开头加
IF @disable_triggers IS NULL THEN ... END IF;，导入前设SET @disable_triggers = 1 - 验证后若耗时回归正常，基本锁定问题；再查
sys.triggers（SQL Server）或pg_trigger（PostgreSQL）确认触发器定义是否含隐式查询或函数调用
禁用后字段自动填充和审计逻辑怎么替代
禁用不是放弃功能，而是换更高效、更可控的方式实现同等效果：
- 时间戳类字段（
created_at、updated_at）：MySQL 8.0+ 改用生成列，ALTER TABLE t ADD COLUMN updated_at DATETIME AS (NOW()) STORED；SQL Server 用DEFAULT GETDATE()或计算列，零触发器开销 - 业务字段补全（如
version、status_code）：由应用层显式传参，避免依赖@user_id或CURRENT_USER()——后者在连接池场景下不可靠，且引发额外权限校验 - 审计日志（如操作人、时间、IP）：改用 outbox pattern，触发器只写轻量消息表（如
outbox_events），由独立作业消费并投递到 Kafka 或写入审计库；不直接 INSERT 到大日志表，避免锁表和 WAL 爆炸 - 统计类更新（如订单总数）：绝对不要在触发器里
UPDATE stats SET count = count + 1；改用 BINLOG 解析（Canal/Maxwell）或应用层发消息异步聚合
哪些场景下还不得不保留触发器
极少数强一致性审计需求可能要求触发器存在，但必须满足全部硬性条件，否则宁可不用：
- 逻辑仅限单条
INSERT INTO audit_log (table_name, row_id, op_time) VALUES ('t', NEW.id, GETDATE())，无SELECT、无函数、无跨库 - 目标日志表已建好非聚集索引，且索引键不含主表任何字段（防止锁升级）
- 数据库已关闭递归：
ALTER DATABASE currentdb SET RECURSIVE_TRIGGERS OFF（SQL Server） - 接受实测性能损失：空壳触发器也会让
BULK INSERT耗时增加 15–30%，复杂逻辑可能翻倍
真正该做的，永远是第一步：确认是否真需要触发器。90% 的所谓“自动同步”逻辑，用应用层事务 + 最终一致性更可控；第二步才是导入前禁用，第三步才考虑补漏——而不是一上来就调优触发器内部 SQL。
