分区表切换前必须验证目标分区为空，因SWITCH是元数据交换而非数据复制；目标非空则报错，需用COUNT(*)或系统视图确认；INSERT归档需控锁、分批、关索引以提升性能。
分区表切换前必须验证目标分区是否为空
分区切换（SWITCH）不是复制数据，而是元数据指针交换，所以目标分区哪怕只有一行，ALTER TABLE ... SWITCH 就会直接报错：The ALTER TABLE SWITCH statement failed. The target table must be empty.
实操建议：
- 每次
SWITCH前用SELECT COUNT(*) FROM target_partition_table确认空状态，别依赖“刚建的表肯定空”——建表后可能被误插、触发器自动填充、或同名表残留 - 若目标是归档表，建议用带时间戳的命名规范，例如
orders_archive_2024Q3，避免复用已有表名 - 切换失败时，
sys.partitions和sys.dm_db_partition_stats可查各分区实际行数，比COUNT(*)更快（尤其大表）
INSERT INTO ... SELECT 需显式控制锁粒度与事务大小
归档老数据常用 INSERT INTO archive_table SELECT ... FROM source_table WHERE ...，但不加约束容易锁表、阻塞业务写入，甚至触发日志爆满。
实操建议：
- 永远加上
WHERE条件，并确保该字段有索引（比如created_at < '2024-01-01'），否则全表扫描 + 大量锁 - 分批次插入：用
TOP (10000)+OFFSET/FETCH或按主键范围切片，单次事务控制在 5 秒内 - 显式指定隔离级别，如
WITH (READPAST)避开被锁行（适合允许跳过少量脏读的归档场景） - 归档表本身建议关闭索引（
DISABLE）再插入，完后再重建，比边插边维护索引快 3–5 倍
分区切换和 INSERT 的性能差异本质在日志与锁
SWITCH 几乎不写日志（只记元数据变更），而 INSERT 每行都生成完整日志记录。同一千万行归档操作，前者秒级完成，后者可能持续十几分钟并占满 tempdb 和事务日志。
但切换有硬性前提：
- 源表与目标表结构必须完全一致（列名、顺序、类型、NULL 性、约束、索引结构）
- 分区函数和分区方案需对齐，连边界值都不能差毫秒（比如
'2024-01-01'和'2024-01-01T00:00:00'在 datetime2 下属于不同分区） - 目标表不能有外键引用，也不能被视图/函数直接引用（除非用 SCHEMABINDING，且需先解绑）
归档后记得更新统计信息和清理旧分区
切换走一个分区后，源表的统计信息不会自动更新，后续查询计划可能劣化；而残留的空分区仍占用系统视图资源，长期积累影响 sys.partitions 查询效率。
实操建议：
- 切换完成后立刻执行
UPDATE STATISTICS source_table，或至少更新涉及分区列的统计项 - 用
ALTER PARTITION FUNCTION ... MERGE RANGE合并已无数据的边界，减少分区数量（注意：合并后无法再拆分） - 如果归档周期固定（如每月），可把分区函数设为右边界 + 循环滑动窗口，避免手动
MERGE和SPLIT
分区切换看着像黑魔法，其实每一步都在绕开 I/O 和日志瓶颈；但只要漏验一个约束、少清一次统计，后面查不出慢在哪，是最常卡住的地方。
