触发器批量插入时只处理第一行是设计使然；应将inserted视为表进行join/merge操作，避免用标量变量赋值导致数据丢失，校验需用集合判断如exists。
触发器在批量插入时只处理第一行，其余数据静默失效——这不是 bug，是设计使然。SQL Server 和 MySQL 的 INSERTED 表天然支持集合操作，但很多人仍用标量变量、SELECT @var = 或 IF EXISTS 写法，结果在线上批量导入时出错。
别用单值变量读取 INSERTED 表
常见错误写法：DECLARE @id INT = (SELECT id FROM INSERTED)，看似简洁，实则危险：当 INSERT 多行时，该语句只返回一行（任意一行），其余数据被忽略。校验、日志、关联更新全部漏掉。
- 正确做法是始终把
INSERTED当作一个「表」来 JOIN 或 MERGE，例如：UPDATE t SET status = 'new' FROM t INNER JOIN INSERTED i ON t.id = i.id - 校验类逻辑（如库存不能为负）必须用集合判断：
IF EXISTS (SELECT 1 FROM INSERTED i LEFT JOIN products p ON i.product_id = p.id WHERE p.stock - i.qty - 测试阶段必须用至少 2 行的语句验证：
INSERT INTO orders VALUES (1,'A'),(2,'B')，不能只测单行
日志类触发器必须批量写入，不能逐行 INSERT
审计日志触发器里写 INSERT INTO audit_log (...) SELECT ... FROM INSERTED 是底线；写 INSERT INTO audit_log VALUES (...),(...) 或循环插入，等于给每行新增加一次磁盘 I/O 和事务日志开销。
- 日志表建议独立库（如
audit_db），避免和业务表争磁盘带宽 - 字段只存关键变更：
table_name、operation_type、new_data（用JSON_OBJECT()或FOR JSON拼接，而非全字段*） - 务必加
BEGIN TRY ... END TRY BEGIN CATCH ... END CATCH，防止日志失败拖垮主事务
WHERE 条件别直接用 INSERTED 做子查询
UPDATE t2 SET flag = 1 WHERE t2.id IN (SELECT id FROM INSERTED) 看似合理，但在 SQL Server 中容易选错执行计划——INSERTED 是内存表，无统计信息，优化器常误判为小结果集，导致嵌套循环而非哈希连接。
- 显式建临时表并加索引：
SELECT id INTO #tmp FROM INSERTED; CREATE INDEX ix_id ON #tmp(id);，再用它 JOIN - 改用
EXISTS更稳定：UPDATE t2 SET flag = 1 WHERE EXISTS (SELECT 1 FROM INSERTED i WHERE i.id = t2.id) - 确认
t2.id字段本身有索引——很多“慢”其实卡在目标表没建好索引
批量导入前该禁用触发器，而不是硬扛
当导入万级数据且触发器含邮件发送、跨库查询或复杂计算时，优化单次逻辑意义不大。执行频次才是瓶颈，不是代码写得不够好。
- 禁用前确认：该触发器是否只用于审计？有没有 CDC、应用监听或复制任务依赖它的副作用？
- 禁用/启用必须在事务外执行：
DISABLE TRIGGER tr_audit ON orders;，否则会报错The context in which the current operation is executing does not allow for transaction control - 导入完成后，若需补日志，应走独立批处理（如定时任务查
last_modified时间戳），而非重新启用触发器回放
真正难的不是写对一句 SQL，而是让整套逻辑在单行、百行、十万行输入下行为一致。触发器没有“调试断点”，只有靠集合思维和严格测试才能避开那些静默丢失数据的坑。
