SQL Server中存储过程不能自动定时执行，必须通过SQL Server Agent作业调度，且作业步骤需显式指定目标数据库上下文，否则默认在master库执行导致“找不到存储过程”错误；Agent服务须运行，作业所有者需具备相应权限；手动触发可快速验证逻辑。
存储过程本身不能定时执行，必须依赖外部调度器——这是所有数据库的共性限制。你写的 CLEANUP_PROC 或 ARCHIVE_DATA 只是逻辑容器，不调用它，它就永远不会运行。
SQL Server：Agent 作业必须指定数据库上下文
很多人建完作业发现 CLEANUP_PROC 根本没执行，查日志只看到 “Could not find stored procedure”。根本原因不是过程写错了，而是作业步骤默认在 master 库下运行，而你的过程实际在 MyAppDB 里。
- 创建作业步骤时，
@database_name参数必须显式填入过程所在库名，不能留空或填master - SQL Server Agent 服务必须处于“正在运行”状态（Windows 服务里确认
SQL Server Agent (MSSQLSERVER)） - 作业所有者账号需有
sysadmin角色，或至少对目标库有EXECUTE权限 + 对msdb的作业管理权限 - 测试阶段别等调度，右键作业 → “Start job at step…” 手动触发更直接
MySQL：EVENT 必须带库名前缀且开启全局调度器
MySQL 的 EVENT 不是作业系统，它只是按时间戳触发 SQL 执行的轻量机制。它无法跨库隐式解析过程名，也不会自动切换上下文。
- 先确保已启用：
SET GLOBAL event_scheduler = ON;，并在my.cnf的[mysqld]段落加event_scheduler=ON持久化 - 事件体中调用过程必须写全路径：
CALL MyAppDB.CLEANUP_PROC();，写成CALL CLEANUP_PROC()会报错 -
STARTS时间必须是未来时间（如'2026-10-01 02:00:00'），设成过去时间会导致状态变为SLAVESIDE_DISABLED且不会自愈 - 事件以
DEFINER账户身份运行，该用户必须对目标表有DELETE权限——仅有EXECUTE权限不够
PostgreSQL：pg_cron 需显式声明 SECURITY DEFINER
pg_cron 是 PostgreSQL 最接近 SQL Server Agent 的方案，但它后台 worker 进程是以 postgres 用户身份连接执行的，不会继承你创建函数时的权限上下文。
- 函数定义必须加上
SECURITY DEFINER，例如：CREATE OR REPLACE FUNCTION archive_old_logs() RETURNS void AS $$ ... $$ LANGUAGE sql SECURITY DEFINER; - 给
postgres用户（或 pg_cron 实际使用的角色）授予该函数的EXECUTE权限：GRANT EXECUTE ON FUNCTION archive_old_logs() TO postgres; - 若执行
SELECT cron.schedule()报错 “function cron.schedule does not exist”，说明扩展未启用：需先在postgres数据库执行CREATE EXTENSION pg_cron; - 避免在函数内使用
NOTIFY或临时表——pg_cron 后台进程可能忽略这些操作
清理逻辑本身必须分批、加索引、带事务控制
无论调度器怎么配，底层清理逻辑写得不稳，照样锁表、超时、丢数据。最常被跳过的三件事是：没索引、没分批、没错误捕获。
- WHERE 条件字段（如
created_at）必须有有效索引；类型要匹配（DATETIME列别用字符串比较） - 大表删除必须分批，每次最多
LIMIT 10000行；用REPEAT ... UNTIL ROW_COUNT() = 0循环，别写单条大 DELETE - 存储过程开头加
START TRANSACTION，结尾显式COMMIT或ROLLBACK；必须用DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获错误 - 归档类操作推荐 “INSERT SELECT + 确认行数 + DELETE” 两步拆解，而不是封装在一个大事务里
最容易被忽略的是归档后数据的可查性：冷备库的字符集、时区、TIMESTAMP/DATETIME 行为是否与源库一致？归档表有没有建对应索引？这些细节不会导致任务失败，但会让后续排查变成噩梦。
