SQL Server 2019 不具备自动识别冷热数据的内置功能，冷热划分必须由业务规则显式定义，常见做法是基于时间字段与阈值判断，并通过 ALTER TABLE ... SWITCH PARTITION 实现高效归档。
SQL Server 2019 本身不提供“自动识别冷热数据”的内置函数或存储过程，所谓智能识别，本质是基于业务规则（如时间、访问频次、状态标记）的显式判断。你不能依赖数据库自己“猜”哪部分是冷数据，必须明确定义冷热边界。
冷热数据的判断逻辑必须由你显式编码
冷热划分不是数据库特性，而是业务策略。常见做法是用时间字段（如 AddDate、ModifiedTime）配合阈值做判断，例如“超过24个月未修改的数据视为冷数据”。这个阈值必须硬编码进存储过程中，或从配置表读取。
- 不要试图用统计信息（如
sys.dm_db_index_usage_stats）实时判断“访问热度”——该视图在重启后清空，且不记录单行级访问，无法支撑可靠冷热决策 - 避免用模糊条件如
WHERE LastAccessTime 而不加索引——这会导致全表扫描，违背分区/归档初衷 - 如果业务允许，建议把冷热标识固化到表中，例如增加
IsCold BIT DEFAULT 0列并建筛选索引，比每次计算更高效
sp_switch_partition 不是冷热识别工具，而是分区切换执行器
很多人误以为 SQL Server 有类似 sp_identify_cold_data 这样的系统存储过程。实际上，冷热数据管理的落地靠的是 ALTER TABLE ... SWITCH PARTITION，而它要求：目标表结构完全一致、位于同一文件组、无约束冲突。存储过程只是封装这个切换动作的外壳。
- 你写的存储过程里真正起作用的是
ALTER TABLE Products SWITCH PARTITION 1 TO Products_Archive这类语句，不是某个智能函数 - 切换前必须确保
Products_Archive表和源分区使用相同文件组，否则报错Msg 4927 - 切换操作本身毫秒级完成，但前提是分区函数已按时间对齐（如每年一个分区），否则需先拆分/合并分区
典型冷热分离存储过程的关键参数与陷阱
一个实用的冷数据归档存储过程通常接受三个核心参数：@CutoffDate（冷数据截止时间）、@TargetArchiveTable（归档目标表名）、@SourcePartitionNumber（待切分区号）。难点不在逻辑，而在运行时校验。
- 必须检查
@CutoffDate是否落在某个分区边界内，可用$PARTITION.pf_OrderDate(@CutoffDate)获取对应分区号，否则切换会失败 - 不能直接传入表名字符串拼接 SQL——需用
QUOTENAME()防注入，例如QUOTENAME(@TargetArchiveTable) - 切换前务必禁用目标表上的外键和触发器，否则报错
Msg 4945；切换后记得重建索引（归档表通常不需要，但要确认） - 事务中执行切换是安全的，但不要包裹大量非切换操作——长时间持有架构锁会影响在线业务
真正容易被忽略的点是：冷热分区策略一旦上线，后续所有 DML（尤其是 INSERT）都必须确保新数据落入最新分区，否则冷热逻辑就失效了。这需要配合分区方案的定期维护（如每月新增一个分区），而不是靠存储过程一次解决。
