SQL Server作业不执行主因是步骤未指定数据库上下文或Agent未启动；MySQL需启用event_scheduler并显式调用带库名的存储过程；PostgreSQL用pg_cron须声明SECURITY DEFINER。
SQL Server 里用 sp_add_job 创建定时清理作业，但作业不执行？
根本原因通常是作业步骤没指定正确的数据库上下文，或代理服务没启动。SQL Server Agent 默认以 master 为默认数据库运行作业，而你的存储过程如果在 MyAppDB 里，又没显式切换库，就会报 Could not find stored procedure 'CleanOldData'。
实操建议：
- 在作业步骤的
Database name字段里明确填入存储过程所在库名，比如MyAppDB，别留空或填master - 检查 SQL Server Agent 服务是否正在运行（Windows 服务里找
SQL Server Agent (MSSQLSERVER)或对应实例名） - 作业所有者账号必须有
sysadmin角色，或至少对目标库有EXECUTE权限 + 对msdb的作业相关权限 - 测试时先手动运行作业（右键 → “Start job at step…”），比等调度更直接
MySQL 没有 SQL Server Agent，怎么让 CleanOldData 定期跑？
MySQL 原生只支持事件调度器（Event Scheduler），它不是“作业系统”，而是基于时间触发的 SQL 执行器，不能调用存储过程以外的逻辑（比如发邮件、写文件），也不能跨库隐式执行——这点常被忽略。
实操建议：
- 确认已启用：执行
SET GLOBAL event_scheduler = ON;，并写入配置文件my.cnf的[mysqld]段落加event_scheduler=ON - 创建事件时必须用
ON SCHEDULE EVERY 1 DAY STARTS '2024-01-01 02:00:00'这类显式时间表达，不能写成EVERY 24 HOUR（语法错误） - 事件体里调用存储过程要加库名前缀，例如
CALL MyAppDB.CleanOldData();，否则在event_scheduler上下文中会找不到 - 事件默认在
definer用户权限下运行，该用户必须对目标表有DELETE权限，仅EXECUTE不够
PostgreSQL 用 pg_cron 调用 clean_old_data()，为什么日志里全是 permission denied for function？
pg_cron 后台 worker 进程是以数据库超级用户（通常是 postgres）身份连接并执行任务的，但它不会自动继承你创建函数时用的 SECURITY DEFINER 行为——除非你显式声明。
实操建议：
- 创建函数时必须加上
SECURITY DEFINER，例如：CREATE OR REPLACE FUNCTION clean_old_data() RETURNS void AS $$ DELETE FROM logs WHERE created_at < NOW() - INTERVAL '30 days'; $$ LANGUAGE sql SECURITY DEFINER;
- 给
postgres用户（或pg_cron实际使用的角色）授予该函数的EXECUTE权限：GRANT EXECUTE ON FUNCTION clean_old_data() TO postgres; - 确保函数内涉及的表，其所属 schema 已加入
search_path，或全部用schema.table全限定名，避免因search_path不一致导致对象解析失败
所有数据库都得注意：清理逻辑本身容易引发锁表或慢查询
哪怕调度配置全对，CleanOldData 一执行就卡住主业务，说明清理方式没做约束。大表删数据不是“删完就完”，是“怎么删才不影响在线服务”。
实操建议：
- 永远避免
DELETE FROM table WHERE ...无限制一次性删几百万行；改用分批，比如 SQL Server 用TOP (10000)+WHILE @@ROWCOUNT > 0循环 - MySQL 中用
DELETE FROM logs WHERE id IN (SELECT id FROM logs WHERE created_at 是错的（子查询不能带 LIMIT），得用临时表或变量模拟分页 - PostgreSQL 推荐用
DELETE FROM logs WHERE id IN (SELECT id FROM logs WHERE created_at ，并确保 <code>id和created_at有联合索引 - 删除后记得
VACUUM（PG）、UPDATE STATISTICS（SQL Server）或ANALYZE TABLE（MySQL），否则查询计划可能持续走错路
最麻烦的不是设不设得成定时任务，而是清理语句在低峰期跑得通，一到白天就锁表、超时、被监控告警打断——这些细节，得在第一次上线前就压测验证。
