分区切换（SWITCH）适合归档删除，因其仅做元数据指针交换、秒级完成、几乎不锁表且日志开销极小；但要求源表与归档表结构、索引、约束严格一致，分区函数与方案对齐，且需手动更新统计信息。
分区切换（SWITCH）为什么适合归档删除
分区切换本身不移动数据，只是元数据层面的指针交换，执行极快、几乎不锁表、事务日志开销极小——这正是归档删除场景最需要的特性。它比 DELETE 逐行删、比 TRUNCATE 全删更精准：能按时间/范围把“旧分区”整个切出去，再单独处理（备份、压缩、删掉），而主表在线业务完全不受影响。
但前提是表必须已启用分区，且目标归档表结构、索引、约束、统计信息必须严格一致，否则 SWITCH 直接报错。
分区函数与分区方案必须对齐归档边界
归档通常按时间（如每月/每季度），分区函数就得用 DATETIME2 或 DATE 类型，并明确定义切割点。比如按月归档 2024 年前数据，分区函数应包含 '2024-01-01' 作为左边界；对应分区方案要把这个分区映射到独立文件组（如 FG_ARCHIVE_2023），避免和在线数据混存。
常见错误是分区函数用了 RANGE RIGHT 却在 SWITCH 时误切到相邻分区，导致数据错位。务必用 sys.partitions 和 sys.dm_db_partition_stats 核对每个分区的行数和边界值。
- 检查当前分区分布：
SELECT $PARTITION.pf_DateRange(CreatedDate) AS partition_number, COUNT(*) FROM dbo.LogTable GROUP BY $PARTITION.pf_DateRange(CreatedDate) - 确认分区方案绑定的文件组：
SELECT destination_id, filegroup_name FROM sys.partition_schemes ps JOIN sys.destination_data_spaces dds ON ps.data_space_id = dds.partition_scheme_id JOIN sys.filegroups fg ON dds.data_space_id = fg.data_space_id WHERE ps.name = 'ps_DateRange'
归档删除的典型三步操作链
不能直接 SWITCH OUT 到一个空表就完事——SQL Server 要求目标表必须存在、结构匹配、且处于同一数据库。标准流程是先建好归档表（含相同索引）、再切换、最后删归档表或转移走。
- 创建归档表（结构完全一致，含相同索引、约束、填充因子）：
CREATE TABLE dbo.LogTable_Archive_2023 (...) ON [FG_ARCHIVE_2023] - 执行切换（原子操作，秒级完成）：
ALTER TABLE dbo.LogTable SWITCH PARTITION 1 TO dbo.LogTable_Archive_2023 - 后续处理：
DROP TABLE dbo.LogTable_Archive_2023（删），或BACKUP DATABASE ... WITH FORMAT（备份归档），或ALTER DATABASE ... REMOVE FILE（清空对应文件组）
注意：SWITCH 不触发触发器，也不记录在事务日志中用于回滚——它一旦提交就不可逆。测试环境务必先用小数据验证分区边界和表结构兼容性。
容易被忽略的权限与维护陷阱
执行 SWITCH 需要 ALTER 表权限，且目标文件组必须有足够空间容纳切换进来的数据。如果归档表建在主文件组，切换后可能意外撑爆 PRIMARY，引发磁盘告警。
另一个隐形坑是统计信息：切换后原表的统计信息不会自动更新，可能导致后续查询计划劣化。建议切换后手动更新：UPDATE STATISTICS dbo.LogTable WITH FULLSCAN，或启用自动更新并观察 sys.dm_db_stats_properties。
最后强调一点：分区切换不是“银弹”。如果表没提前设计分区、或者历史数据量不大（比如几百万行以下），硬上分区反而增加维护复杂度。此时用带 TOP N 的分批 DELETE + CHECKPOINT 可能更简单可靠。
