SQL Server存储过程无法自动定时运行，须依赖SQL Server Agent调度；归档逻辑需手动编写，不能靠ALTER PROCEDURE自动推日期，边界条件如WHERE OrderDate >= '2026-08-01'必须显式定义。
SQL Server 本身不支持“存储过程自动定时运行”，必须依赖 SQL Server Agent 调度，否则脚本写得再完整也永远不会执行。
归档逻辑必须手动写，不能靠 ALTER PROCEDURE 自动推日期
很多人以为建个 CREATE PROCEDURE ArchiveOrdersByMonth，里面用 DATEPART(MONTH, OrderDate) 就能自动归档当月数据——其实不行。归档边界必须显式定义，比如：
WHERE OrderDate >= '2026-08-01' AND OrderDate ，不能写成 <code>WHERE DATEPART(MONTH, OrderDate) = DATEPART(MONTH, GETDATE())，后者无法走索引，且跨年会出错- 目标归档表（如
orders_archive_202608）必须提前建好，结构、主键、索引与源表一致；否则INSERT INTO ... SELECT会失败或极慢 - 大表归档务必加事务 +
XLOCK提示：BEGIN TRAN; INSERT INTO ... WITH (XLOCK) SELECT ... FROM orders WHERE ...; DELETE FROM orders WITH (XLOCK) WHERE ...; COMMIT;
清理日志类数据，DELETE 必须配索引和分批
直接 DELETE FROM logs WHERE created_at 是高危操作，尤其在没索引时等于锁全表。
-
created_at字段必须有非聚集索引，且最好包含INCLUDE常用查询字段，避免 Key Lookup - 永远不要在 WHERE 里反复调用
GETDATE()；改用DECLARE @cutoff DATETIME2 = DATEADD(day, -30, GETDATE())预计算 - 单次删超 5000 行就可能触发锁升级，必须分批：
DELETE TOP (5000) FROM logs WHERE created_at - 如果表已按月分区（如
logs_202607），优先DROP TABLE logs_202607，比 DELETE 快两个数量级
Agent 作业配置最容易漏掉的三件事
用 SSMS 图形界面点出来的作业，常因权限、日志、错误处理缺失而静默失败。
- 作业步骤的子系统必须选
TSQL，不是CmdExec；命令里写EXEC ArchiveOrdersByMonth，别漏EXEC - 必须为作业指定
@owner_login_name（如'sa'或域账号），否则默认用创建者 Windows 账号，该账号一禁用，作业立即停摆 - 在作业属性 → 通知 → “当作业完成时写入 Windows 应用程序日志”要勾上，否则失败无痕迹；
sp_add_jobstep中建议加@on_fail_action = 2（转到下一步）或3（失败），别留默认值
最常被忽略的是：归档和清理操作都依赖统计信息准确性，sys.dm_db_partition_stats 查行数比 COUNT(*) 快得多，但前提是统计信息不过期——别忘了定期更新。
