不能在触发器中拼接表名执行动态SQL，因会绕过权限检查、污染执行计划缓存，且主表插入成功而动态SQL失败时事务无法回滚，导致数据错位；必须用IF/CASE硬编码分支，基于INSERTED字段显式插入对应分区表，并确保结构、权限、统计信息严格一致。
不能靠触发器“自动创建分区”或“动态改写INSERT目标表”，必须用硬编码路由逻辑 + 严格结构对齐 + 事务内显式插入。
为什么不能在触发器里拼接表名再EXEC
常见错误是写类似 EXEC('INSERT INTO orders_' + @year + ' SELECT * FROM INSERTED')。这会绕过静态权限检查，导致执行计划缓存污染；更严重的是，一旦主表插入成功但动态 SQL 失败（比如目标表不存在、列不匹配），整个事务不会回滚主表操作——数据就错位了。SQL Server 触发器运行在语句级事务中，只有显式 INSERT INTO target_table SELECT * FROM INSERTED 这种形式才能绑定到同一事务上下文，保证原子性。
如何用IF/CASE判断并路由到具体分区表
必须基于 INSERTED 中的业务字段（如 order_date）做硬分支判断，不能依赖 GETDATE()：
IF EXISTS (SELECT 1 FROM INSERTED WHERE order_date <= '2024-03-31') INSERT INTO orders_q1_2024 SELECT * FROM INSERTED WHERE order_date <= '2024-03-31'IF EXISTS (SELECT 1 FROM INSERTED WHERE order_date BETWEEN '2024-04-01' AND '2024-06-30') INSERT INTO orders_q2_2024 SELECT * FROM INSERTED WHERE order_date BETWEEN '2024-04-01' AND '2024-06-30'- 所有
INSERT必须带WHERE子句过滤对应行，避免重复插入 - 禁止用游标或循环逐行处理——性能差、易死锁
分区表结构和权限有哪些硬性要求
所有目标分区表必须与主表完全一致：
- 列名、顺序、类型、NULL 属性、默认值、计算列定义全部相同
- 主键、唯一约束、检查约束需一一对应（否则
INSERT INTO ... SELECT FROM INSERTED会报错） - 触发器所在用户必须对每个分区表有
INSERT权限（不能只给主表权限） - 禁用嵌套触发器（
sp_configure 'nested triggers', 0），否则可能引发无限递归
日志记录和性能瓶颈怎么规避
如果要记路由日志，别用普通 INSERT INTO route_log：
- 加
WITH (TABLOCK)减少锁竞争：INSERT INTO route_log WITH (TABLOCK) (table_name, row_count) SELECT 'orders_q2_2024', COUNT(*) FROM INSERTED WHERE ... - 避免在触发器里调用链接服务器、远程存储过程或 HTTP 请求——失败即导致主表插入回滚
- 分区表数量不宜过多（建议单表不超过 50 个），否则 IF 分支过长，编译耗时增加，执行计划缓存压力大
真正容易被忽略的是：分区表的统计信息必须定期更新，否则优化器无法准确估算各分区行数，可能导致查询计划退化——哪怕路由逻辑完全正确，查起来也慢。
