SQL Server触发器需用IF/CASE判断INSERTED字段值（如order_date）显式插入对应分区表，不可动态拼接SQL；所有分区表结构须与主表一致，事务天然一致，但须授予权限并避免嵌套触发器。
触发器里怎么判断该插到哪个分区表
SQL Server 本身不支持像 MySQL 那样在 INSERT 时由触发器动态改写目标表（比如把 INSERT INTO orders 改成 INSERT INTO orders_2024），所以不能靠“重定向插入语句”实现路由。真正可行的方式是：在触发器中用 IF/CASE 判断业务字段（如 order_date、region_id），再显式调用对应分区表的 INSERT。
常见错误是试图在触发器里拼接表名后用 EXEC(@sql)，这会绕过静态权限检查、引发执行计划缓存污染，且无法保证事务一致性——万一主表插入成功但动态 SQL 失败，数据就错位了。
- 必须用硬编码或查配置表映射分区逻辑（例如：日期 ≤ '2024-03-31' → 插入
orders_q1_2024） - 所有目标分区表结构必须与主表完全一致（含约束、默认值、计算列），否则触发器内
INSERT会报错 - 避免用
GETDATE()做分区依据——它可能和事务开始时间不一致；应优先用被插入行的字段值（如INSERTED.order_date）
如何保证主表 INSERT 和分区表 INSERT 的事务一致性
触发器运行在主表 INSERT 的同一事务上下文中，只要不显式 COMMIT 或 ROLLBACK，整个操作天然具备原子性。但要注意：如果分区表上存在触发器、外键或级联操作，可能隐式延长锁持有时间，导致阻塞。
- 触发器内所有
INSERT必须使用INSERT INTO target_table (...) SELECT ... FROM INSERTED形式，不能用循环逐行处理（性能差、易死锁） - 禁止在触发器中调用可能失败的外部过程（如链接服务器查询、HTTP 调用），否则主表插入会被回滚
- 若需记录路由日志，建议用
INSERT INTO route_log WITH (TABLOCK)避免日志表成为瓶颈
为什么不能直接用 SQL Server 原生分区表替代触发器路由
SQL Server 的原生表分区（Partitioned Table）是存储层逻辑，对应用透明，不解决“按业务规则分库/分表”的需求。它只支持按单列做范围/列表分区，且分区函数和方案一旦绑定，修改成本高（需重建索引）。而触发器路由本质是应用层分表，能支持多条件组合（如 region_id IN (1,2) AND order_date >= '2024-01-01'），也便于跨数据库甚至跨实例部署。
- 原生分区表仍共用一个
sys.partitions元数据，无法隔离权限或备份策略 - 触发器路由后的各分区表可独立建索引、压缩、归档，灵活性更高
- 但代价是：丢失唯一约束跨表保证（如全局订单号唯一需额外维护）、
SELECT *必须改写为UNION ALL显式合并
触发器里插入分区表时容易忽略的权限和性能点
触发器以执行 INSERT 的用户身份运行，但该用户未必有对分区表的 INSERT 权限——尤其当分区表在另一 schema 或 database 时。同时，每个 INSERT ... SELECT FROM INSERTED 都会触发一次分区表的触发器（如果存在），形成嵌套调用链。
- 必须显式授予用户对所有目标分区表的
INSERT权限，不能依赖db_datawriter角色（它不跨库生效） - 分区表上禁用
AFTER INSERT触发器，否则可能无限递归；如需审计，改用INSTEAD OF INSERT+ 显式插入 + 日志表 - 大量并发插入时，
INSERTED表可能含数百行，触发器内应避免对每行做 UDF 计算或子查询，优先用集合运算
触发器路由不是银弹：它掩盖了分表带来的查询改写、统计信息分散、分布式事务缺失等问题。上线前务必压测分区表的 INSERT 吞吐量，确认比单表慢不超过 15% —— 超过这个阈值，说明触发器逻辑或分区设计已成瓶颈。
