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