SQL存储过程本身不能创建定时任务，必须依赖外部调度机制：MySQL用EVENT（需启用event_scheduler）、SQL Server用SQL Server Agent、PostgreSQL用pg_cron扩展；禁止在过程中用SLEEP或WAITFOR模拟定时。
SQL存储过程本身不能直接创建定时任务
存储过程只是数据库内的一段可执行代码，不具备调度能力。所谓“在存储过程中编写定时任务”，本质是两件事：先写好清洗逻辑（存为存储过程），再用外部调度机制定期调用它。常见错误是试图在 CREATE PROCEDURE 里写 SLEEP() 或循环等待时间——这会阻塞连接、耗尽会话资源，且无法精准控制周期。
真正可行的路径只有两条：
- 数据库原生调度器（如 MySQL 的
EVENT、SQL Server 的 SQL Agent、PostgreSQL 的pg_cron） - 外部调度工具（如 Linux
cron+mysql命令、PythonAPScheduler、Airflow）
MySQL 中用 EVENT 调用清洗存储过程最轻量
如果用的是 MySQL 5.1+ 且 event_scheduler 已启用（检查 SHOW VARIABLES LIKE 'event_scheduler'; 返回 ON），这是最贴近“数据库内闭环”的方案。注意：EVENT 是独立对象，不是存储过程的一部分，必须单独创建。
典型写法：
CREATE EVENT clean_user_logs_event ON SCHEDULE EVERY 1 DAY STARTS '2024-01-01 02:00:00' DO CALL clean_user_logs();
关键点：
-
clean_user_logs()必须是已存在的存储过程，且定义中不含READS SQL DATA以外的特性（比如不能有临时表嵌套调用限制） - 默认事件作用域是当前数据库，跨库调用需显式写成
database_name.clean_user_logs() - 若清洗过程可能超时，务必在存储过程中设置
SET SESSION max_execution_time = 30000;防止被 kill 后事件静默失败
SQL Server 存储过程 + SQL Agent 是生产首选
SQL Server 没有类似 MySQL EVENT 的轻量机制，SQL Server Agent 是官方支持的调度服务。它的优势在于失败告警、运行日志、依赖步骤编排——适合清洗逻辑复杂、需监控的场景。
操作要点：
- 确保 SQL Server Agent 服务已启动（Windows 服务列表里找
SQL Server Agent (INSTANCE_NAME)） - 新建作业时，“步骤类型”选
Transact-SQL script (T-SQL)，内容就是EXEC clean_user_logs; - 不要在存储过程中用
WAITFOR DELAY模拟定时——它只阻塞当前会话，不触发下一次执行 - 若清洗涉及大量 DELETE，建议分批提交（例如每次删 5000 行 +
WAITFOR DELAY '00:00:01'），避免事务日志暴涨
PostgreSQL 需额外扩展 pg_cron
PostgreSQL 默认无内置调度，必须安装 pg_cron 扩展（9.6+ 支持）。它以 extension 形式运行，调度指令写在 SQL 里，语法接近 cron 表达式。
启用后调用清洗过程示例：
SELECT cron.schedule('0 2 * * *', $$CALL clean_user_logs()$$);要注意：
- 扩展需在
postgresql.conf的shared_preload_libraries中添加pg_cron并重启服务 - 调度用户必须有
USAGE ON SCHEMA cron和EXECUTE ON FUNCTION cron.schedule()权限 -
pg_cron的 job 日志不进 PostgreSQL 主日志，需查cron.job_run_details表跟踪失败原因
跨数据库或需要重试机制时，别硬塞进单个存储过程里——调度和执行职责分离才容易定位问题。比如某次清洗因锁表失败，你得能快速判断是调度没触发、过程卡死、还是权限不足，而不是在一堆 BEGIN...END 里翻日志。
