很多人在问：存储过程能不能自己定时执行？答案是——不能。存储过程本身只是一段被调用时运行的逻辑代码，它没有内置的“闹钟”。真正实现定时清理，必须依赖数据库自带的作业调度机制。下面分别看看三大主流数据库的实战方案，以及一些容易被忽略的坑。
SQL Server 中用 sp_add_job 创建定时清理作业
存储过程本身不能“定时执行”，它只是被调用时运行的一段逻辑。真正常见的定时清理方案，是在 SQL Server Agent 里建一个作业（Job），让这个作业定期调用你的清理存储过程。关键前提是 SQL Server Agent 必须正在运行——很多开发环境默认没启这个服务，直接配置会失败。
实操建议：
- 先在 SSMS 中右键「SQL Server Agent → 启动」，确认服务状态为“正在运行”
- 用
sp_add_job、sp_add_jobstep、sp_add_schedule三步注册作业，其中@command参数必须写成EXEC YourCleanupProc形式，不能带数据库名前缀（如EXEC MyDB.dbo.YourCleanupProc）除非你在@database_name参数里明确指定 - 调度时间用
@freq_subday_type = 4（每分钟）或@freq_type = 4（每天）更稳妥，避免用@freq_type = 1（一次性）误配
PostgreSQL 中用 pg_cron 扩展替代原生定时器
PostgreSQL 没有内置的作业调度器，pg_cron 是最接近 SQL Server Agent 的方案，但它不是默认安装的扩展，需要手动启用。一旦装好，就能直接在 SQL 里用 cron.schedule() 调用函数，包括封装了 DELETE 逻辑的存储过程。
常见错误现象：
- 执行
SELECT cron.schedule(...)报错 “function cron.schedule does not exist”，说明扩展未创建：需先用CREATE EXTENSION pg_cron（注意：必须在postgres数据库执行） - 清理函数里用了临时表或
NOTIFY，可能被pg_cron后台进程忽略——这类操作建议移到主函数外处理 - 日志表上有大范围
DELETE，没加LIMIT控制单次删量，容易锁表或触发 WAL 暴涨；推荐改用分批删除，例如每次删 10000 行，循环直到无数据
MySQL 8.0+ 用事件调度器（Event Scheduler）但慎用 EVENT 直接删数据
MySQL 的 EVENT 确实能定时执行 SQL，但直接在里面写大 DELETE 很危险：事件是单线程执行，若某次清理卡住（比如 WHERE 条件没走索引），后续调度会被阻塞，甚至堆积多个未执行任务。
使用场景建议：
- 只用
EVENT触发调用存储过程，把实际清理逻辑封装进过程里，便于调试和限流 - 确保日志表的过期字段（如
created_at）上有索引，否则WHERE created_at < ...会全表扫描 SET GLOBAL event_scheduler = ON必须执行，且 MySQL 配置文件中event_scheduler=ON要持久化，否则重启后失效
跨数据库通用的清理逻辑设计要点
不管用哪种调度机制，清理语句本身的设计比调度方式更容易出问题。特别是高并发写入的日志表，一次删几百万行可能引发主从延迟、备份中断或连接超时。
参数差异与性能影响：
- 别用
DELETE FROM logs WHERE created_at < ...这种无限制语句；改用DELETE FROM logs WHERE id IN (SELECT id FROM logs WHERE created_at < ... LIMIT 10000)分批删 - 如果日志表支持按时间分区（如 PostgreSQL 的 range 分区、MySQL 5.7+ 的 PARTITION BY RANGE），优先用
DROP PARTITION替代 DELETE，速度差一个数量级 - 清理后记得
VACUUM（PostgreSQL）或OPTIMIZE TABLE（MySQL），否则磁盘空间不释放，旧数据页仍占位
最容易被忽略的是权限——SQL Server Agent 作业默认以 NT SERVICESQLSERVERAGENT 身份运行，它未必有目标数据库的 db_datawriter 权限；pg_cron 后台进程用的是启动 PostgreSQL 的系统用户，可能没权限访问某些 schema。这些得提前验证，不能等调度失败才查。
