PARTITION SWITCH 删除整月数据仅需几秒，因它仅修改元数据；而 DELETE 逐行操作会触发完整日志记录、锁升级、索引维护及复制分发压力，导致日志暴涨、严重阻塞。
直接用 PARTITION SWITCH 删除整个月份的数据，通常只要几秒；而 DELETE 同等数据量可能跑几小时甚至失败。
为什么不能直接 DELETE 大量历史数据
逐行 DELETE 会触发完整事务日志记录、锁升级（从行锁升到表锁）、索引维护开销大，还容易阻塞其他查询。尤其在高并发或复制环境中，DELETE 会把每条变更都发往分发器，带宽和延迟压力巨大。
- 日志暴涨：删除 1000 万行可能生成数 GB 日志
- 锁等待严重：
DELETE FROM Sales WHERE SaleDate 可能让报表查询卡住十几分钟 - 复制环境禁用
TRUNCATE，但DELETE又太慢——这是分区切换最典型的驱动力
必须提前建好的 4 个核心对象
分区切换不是“开关一按就生效”，它依赖底层结构严格对齐。缺任何一个，ALTER TABLE ... SWITCH 会报错，比如 The ALTER TABLE SWITCH statement failed. There is no identical index in the source table。
-
PARTITION FUNCTION：定义切分逻辑，例如按datetime列做RANGE RIGHT，值为'2025-01-01'和'2025-02-01' -
PARTITION SCHEME：把函数结果映射到具体文件组，注意末尾要留一个空分区（如用[PRIMARY]），否则无法切换出旧分区 - 源表（已分区的主表）：必须有与目标表完全一致的列定义、约束、索引结构（含填充因子、排序方向）
- 目标表（空的占位表）：结构相同、同分区方案（或
ON [PRIMARY]）、无数据、无外键引用——常命名为Sales_staging_drop_202401
执行 SWITCH 的最小安全操作序列
切换本身是元数据操作，不移动数据页，所以快。但前提是两边结构 100% 匹配，且目标表必须为空、未被引用。
- 先确认要删的是哪个分区：
SELECT $PARTITION.your_pf_name(SaleDate) FROM Sales WHERE SaleDate = '2024-01-15' - 创建结构一致的目标表（用
CREATE TABLE ... ON [PRIMARY]，别用分区方案） - 执行切换：
ALTER TABLE Sales SWITCH PARTITION 1 TO Sales_staging_drop_202401（假设分区 1 是 2024 年 1 月） - 立刻
DROP TABLE Sales_staging_drop_202401—— 这才是真正释放空间的一步
整个过程不需要 WAITFOR，也不需要停业务。但注意：切换期间源表对应分区不可写（毫秒级），如果应用频繁写入该时间范围，需避开高峰或加重试逻辑。
最容易被忽略的兼容性陷阱
看似简单的 SWITCH 在真实环境里失败率很高，问题往往出在“看起来一样，其实不一样”：
- 源表和目标表的
IDENTITY属性必须完全一致（都启用或都禁用） - 所有索引（含唯一约束）必须名称不同、定义相同，且都建在相同分区方案上（或都建在
[PRIMARY]） - 如果源表有
FILESTREAM列或SPARSE列，目标表也必须有，否则报错 - SQL Server 标准版不支持将分区切换到不同文件组——只能切到
[PRIMARY]，企业版才支持跨文件组自由切换
真正上线前，务必在测试库用 DBCC SHOW_STATISTICS 和 sys.dm_db_partition_stats 核对两边行数、分区 ID、索引深度是否完全一致；任何微小偏差都会让 SWITCH 直接拒绝执行。
