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 <p>这样避免中间状态，也减少锁持有时间。但要注意：</p>

• 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

归档逻辑越简单越好，调度越独立越好。别想着“一次写完通用方案”，每个数据库的锁机制、事务可见性、日志行为都不同，照搬代码大概率半夜收告警。