分区切换能秒级替代DELETE，因为SWITCH是元数据操作，仅更新系统表中分区所属对象ID，不移动数据页；而DELETE需逐行标记、写日志、加锁，易引发阻塞与日志膨胀。
分区切换为什么能秒级替代DELETE
因为 SWITCH 是元数据操作，不移动实际数据页，只要源表和目标表结构完全一致（含索引、约束、统计信息状态），SQL Server 仅更新系统表中分区所属对象ID，耗时通常在毫秒级。而 DELETE 会逐行标记、写日志、触发锁和事务日志增长，百万级以上数据删除可能卡住阻塞链、拖慢日志备份甚至填满日志文件。
执行 SWITCH 前必须满足的5个硬性条件
缺一不可，否则直接报错 The ALTER TABLE SWITCH statement failed. The target table 'xxx' must be empty. 或更隐蔽的 Cannot switch a partition that contains LOB data：
- 源表和目标表必须位于同一数据库、同一文件组（或都启用
DATA_COMPRESSION且压缩类型一致） - 两表必须有完全相同的列定义：顺序、名称、数据类型、NULL 属性、排序规则（
COLLATE）、是否为计算列或标识列 - 目标表（即将接收分区的空表）不能有任何索引——但可以有与源表分区对齐的相同结构的聚集索引（即也要按同一分区函数和方案创建）
- 源表必须已按目标分区函数进行分区（即已建好
PARTITION SCHEME和FUNCTION），且要切换的分区当前非空 - 目标表不能有外键引用，也不能被外键引用；不能有启用的变更数据捕获（CDC）或变更跟踪（CT）
典型操作流程：从“删旧数据”到“切走旧分区”
假设按月分区的销售表 Sales，想清掉 2023 年以前所有数据：
1. 先建一个与 Sales 结构完全一致的空表 Sales_Staging，并用同一分区函数和方案创建（即使它只映射到单一分区）：
CREATE TABLE Sales_Staging (
SaleID INT NOT NULL,
SaleDate DATE NOT NULL,
Amount DECIMAL(18,2)
) ON PS_SaleDate(SaleDate); -- PS_SaleDate 是按 SaleDate 分区的 scheme2. 确保 Sales_Staging 当前无数据、无索引、无约束；然后执行切换（例如把第 1 号分区切过去）：
ALTER TABLE Sales SWITCH PARTITION 1 TO Sales_Staging PARTITION 1;
3. 切完立刻 DROP TABLE Sales_Staging —— 这才是真正释放空间的一步，但它是 DDL，不走完整事务日志，也极快。
注意：如果原表是按 RANGE RIGHT 定义的分区函数，且你想删的是最早分区（如 '2023-01-01' 之前），需确认该分区确实对应 PARTITION 1，可用 $PARTITION.PF_SaleDate('2022-12-31') 验证。
容易被忽略的三个坑
一是统计信息不会自动更新：切换后 Sales 表的统计信息仍包含已切走分区的数据量，导致后续查询计划劣化，必须手动运行 UPDATE STATISTICS Sales；
二是如果源表有非对齐索引（比如某个索引没按分区函数建立），SWITCH 会直接失败，错误提示里不明确说“非对齐”，而是报 Partition is not aligned with the partition function；
三是时间字段若用 DATETIME2(7) 而分区函数边界值用 DATE，类型隐式转换会导致分区无法对齐——务必让边界值类型与分区列完全一致。
