bulk insert默认跳过触发器是sql server的设计行为而非bug，它绕过约束检查、日志记录和触发器执行；只有显式dml语句（如insert/update/delete）才激活触发器。
BULK INSERT 默认跳过触发器是设计行为，不是 bug
SQL Server 的 BULK INSERT 从一开始就没打算走标准 DML 路径——它绕过约束检查、日志记录、伪表（inserted/deleted）生成，自然也不触发任何 AFTER INSERT 或 INSTEAD OF 触发器。这不是配置遗漏或版本差异，而是高吞吐场景下的底层优化选择。
验证很简单：在触发器里加 PRINT 'fired' 或写日志表，执行 BULK INSERT 后查不到输出；换成普通 INSERT 就立刻生效。别花时间 debug 触发器逻辑，先确认你用的到底是不是触发器支持的操作。
哪些批量导入方式会/不会触发触发器
不同命令对触发器的支持差异极大，不能凭名字猜：
-
BULK INSERT和bcp命令：默认 不触发，哪怕触发器状态是is_disabled = 0 -
INSERT INTO ... SELECT * FROM OPENROWSET(BULK ...)：默认 会触发，因为它本质是 T-SQL DML 语句 -
SqlBulkCopy（.NET 类）：默认 不触发，但可设FireTriggers = true -
TRUNCATE TABLE：永远不触发，它是 DDL，连伪表都不生成 -
LOAD DATA INFILE（MySQL）：官方明确写 “does not activate triggers”，同理
想让批量数据走触发器，得换路径
硬要保留触发器逻辑，就不能依赖原生 BULK INSERT 直入目标表。可行方案只有两个方向：
- 先
BULK INSERT到临时表（如#staging），再用INSERT INTO real_table SELECT * FROM #staging—— 这条INSERT会触发 - 改用
INSERT INTO ... SELECT * FROM OPENROWSET(BULK ...)，并确保没加WITH (IGNORE_TRIGGERS)提示 - 若用
SqlBulkCopy，必须显式设置bulkCopy.FireTriggers = true，否则即使代码里写了触发器也白搭
注意：SELECT INTO 创建新表时，目标表还不存在，触发器根本没地方挂，所以也不会触发。
启用 FIRE_TRIGGERS 参数的坑
BULK INSERT 支持 FIRE_TRIGGERS 参数，但实际用起来容易翻车：
- 它只对当前语句生效，不能全局开启；漏写就静默失效
- 触发器会被执行，但所有行共用一个上下文（即整个批次只触发一次），
inserted表里是全部新行——如果触发器里有基于单行逻辑（比如调用标量函数、发邮件），性能可能断崖下跌 - 若触发器内含事务控制（
BEGIN TRAN）、错误处理不当，或引用了不存在字段，整个BULK INSERT会失败，且错误信息常被吞掉，得查ERRORFILE或开SET XACT_ABORT ON - Azure SQL 托管实例和 Fabric 数据仓库中，
FIRE_TRIGGERS参数虽存在，但在某些版本中实际不起作用，需实测验证
真正麻烦的不是“怎么让它触发”，而是“触发后它能不能稳住”——大批量下触发器变成性能瓶颈或单点故障，比不触发更难收场。
