SQL Server原生不支持自动按日期归档，必须用SQL Server Agent调度T-SQL脚本实现；关键在于自定义归档逻辑（如按OrderDate边界）和正确调用sp_add_job配合sys.dm_db_partition_stats。
SQL Server 里用 sp_add_job 配合 sys.dm_db_partition_stats 做按月归档最稳
直接说结论：SQL Server 原生不支持“自动按日期归档”的存储过程调度，必须靠 SQL Server Agent + T-SQL 脚本组合实现。别指望写个 CREATE PROCEDURE ArchiveByDate 就能自己跑起来。
关键在两点：一是归档逻辑得自己写清楚边界（比如只搬 OrderDate 的数据），二是调度必须用 Agent Job，不能依赖应用层或 Windows 任务计划——后者容易漏跑、没日志、权限错乱。
- 归档前先查目标表的行数和索引碎片：
sys.dm_db_partition_stats比COUNT(*)快得多，尤其大表 - 迁移用
INSERT INTO ... SELECT ...后立刻DELETE，别用SELECT INTO——后者会锁整个源表，且无法回滚 - 务必在事务里做
INSERT+DELETE，并加XLOCK提示防止并发冲突 - 目标归档表必须提前建好，结构一致、主键/索引对齐；否则
INSERT会失败或极慢
MySQL 8.0 用事件调度器（EVENT）+ PARTITION 表省力但有坑
MySQL 原生支持定时触发，但 EVENT 默认是禁用的，得先开：SET GLOBAL event_scheduler = ON。不开就永远不执行，连错误都不报。
真正省事的是配合分区表：比如按 RANGE COLUMNS(OrderDate) 分区，归档时直接 ALTER TABLE orders DROP PARTITION p_202309，比 DELETE 快百倍。但注意：
-
EVENT默认用DEFINER权限运行，如果创建者账号被删或密码改了，事件就静默失效 - 分区字段必须是整型或日期型，且不能是表达式；
OrderDate + INTERVAL 1 DAY这种写法不支持分区 - 删除分区后，对应数据彻底消失，没有回收站，也没 binlog 记录完整行镜像（除非开
binlog_format = ROW） - 别在
EVENT里调用存储过程再做复杂判断——事件本身超时默认 60 秒，超时就中断，不重试
PostgreSQL 用 pg_cron 扩展比 pgAgent 更可靠
pg_cron 是官方推荐的扩展，直接集成进数据库进程，调度精度到秒，失败自动重试；而 pgAgent 是外部服务，挂了就停，还得单独维护进程和服务账户。
归档逻辑建议用 CTE + RETURNING 一次完成迁移和清理：
WITH moved AS ( DELETE FROM orders WHERE order_date < CURRENT_DATE - INTERVAL '3 months' RETURNING * ) INSERT INTO orders_archive SELECT * FROM moved;
这样避免中间状态，也减少锁持有时间。但要注意：
-
pg_cron必须在shared_preload_libraries里显式启用，重启才生效；光CREATE EXTENSION不够 - 归档表的
oid和约束名最好和原表不同，否则跨库同步或逻辑复制时容易冲突 - 如果用了
IDENTITY列，INSERT INTO ... SELECT会报错，得显式列出所有字段，跳过 identity 列
所有数据库都绕不开的三个隐形雷区
归档不是“跑通就行”，线上出问题往往卡在这三处：
- 没设
LOCK_TIMEOUT（SQL Server）或lock_timeout（PostgreSQL）：一个长事务卡住归档，后续调度全堆积，最后爆满 msdb 或 cron.job 表 - 归档脚本里硬编码了表名或日期格式，比如写死
'2023-09-01'——下次月份一变就失效，必须用FORMAT(GETDATE(), 'yyyyMM')或TO_CHAR(CURRENT_DATE, 'YYYYMM')动态生成 - 忽略统计信息更新：归档后源表数据量剧减，但优化器还按旧统计走执行计划，可能导致下一次归档变慢十倍；SQL Server 要手动
UPDATE STATISTICS，PG 要ANALYZE
归档逻辑越简单越好，调度越独立越好。别想着“一次写完通用方案”，每个数据库的锁机制、事务可见性、日志行为都不同，照搬代码大概率半夜收告警。
