不能直接用 select into 归档老数据，因为它会创建新表，而归档需写入已存在的历史表且保持结构、约束、索引一致；必须通过事务保障插入→删除→校验三步原子性闭环。
为什么不能直接用 SELECT INTO 归档老数据？
因为 SELECT INTO 会创建新表，而归档必须写入已存在的历史表（如 Orders_Archive_2023），且需保持结构、约束、索引一致。更关键的是，生产环境要求原子性：归档和删除必须成对执行，否则中间失败会导致数据丢失或重复。
如何安全地把 Orders 表中 2023 年前的数据移到归档表？
核心是三步闭环：插入 → 删除 → 校验，全部包裹在事务里。归档表必须预先建好，字段、类型、NULL 属性严格对齐源表（建议用 SELECT TOP 0 * + INTO 初始化一次，之后只增列不改类型）。
实操要点：
- 用
WHERE OrderDate 而不是 <code>，避免时区或 datetime 精度导致漏数据 - 删除前加
WITH (TABLOCKX)防止大表扫描时被其他查询阻塞 - 归档后立即查
@@ROWCOUNT，若插入行数 ≠ 删除行数，说明有触发器/约束干扰，需中断并告警 - 示例关键片段：
BEGIN TRY BEGIN TRANSACTION; INSERT INTO Orders_Archive_2023 WITH (TABLOCK) SELECT * FROM Orders WHERE OrderDate (SELECT COUNT(*) FROM Orders_Archive_2023 WHERE OrderDate
分表命名怎么动态生成又不引发 SQL 注入？
不能拼接表名进 SQL 字符串。T-SQL 没有参数化对象名，必须用 QUOTENAME() 严格包裹用户输入的年份或分区标识。
正确做法：
- 传入参数用
@Year INT，而非@TableName NVARCHAR(128) - 构造表名：
DECLARE @ArchiveTable SYSNAME = QUOTENAME('Orders_Archive_' + CAST(@Year AS VARCHAR(4))); - 动态执行时，只拼接已验证的
@ArchiveTable，其余条件仍用参数化（如@CutoffDate） - 务必检查
@Year范围（比如只允许 2020–2030），防止生成非法表名
归档过程卡死或超时怎么办？
大表归档最常卡在锁等待或日志暴涨。解决方案不是调高 timeout，而是拆解操作粒度：
- 用
TOP (10000)分批处理，每次事务控制在 10 秒内；循环中加WAITFOR DELAY '00:00:00.1'避免占满 CPU - 归档表必须关闭聚集索引（如果源表有），或提前建好相同结构的空表 + 禁用索引，归档完再重建
- 确保
tempdb和日志文件有足够空间——归档期间INSERT ... SELECT会产生大量日志，简单恢复模式下也逃不掉 - 别依赖
sp_who2查阻塞，用sys.dm_exec_requests+blocking_session_id定位真实源头
真正麻烦的永远不是语法，而是归档窗口期和业务写入的冲突。哪怕脚本完全正确，没协调好应用停写或读写分离切换，照样出事。
