SQL存储过程不能自行定时执行，必须依赖外部调度机制：SQL Server需用SQL Server Agent（服务启用、权限配置、三段式调用），MySQL需开启event_scheduler并授权EVENT权限，且均须注意数据库上下文、时区与权限链。
SQL 存储过程本身不能“自己定时执行”——它只是数据库里一段可调用的代码，没有内置调度能力。真要让 DailyCleanup 或 PROC_MYPROCEDURE 每天凌晨跑一次，必须靠外部调度机制驱动，不是在存储过程里写 WAITFOR 或循环等待。
SQL Server 必须用 SQL Server Agent，别碰 WAITFOR
有人在存储过程里写 WAITFOR DELAY '00:01:00' 加循环，想模拟定时，这完全错误：它会一直占着一个连接、阻塞事务、无法被可靠终止，且服务重启后自动失效。
- 正确路径只有一条：
SQL Server Agent服务必须运行（Windows 服务中找SQL Server Agent (MSSQLSERVER)或带实例名的项） - 作业所有者账户需有
sysadmin角色，或至少在msdb库中被授予SQLAgentOperatorRole - 作业步骤的“数据库”下拉框必须手动选中你的业务库（比如
YourDBName），不能只写EXEC MyProc—— 否则报错Could not find stored procedure 'MyProc' - 计划配置里两个开关缺一不可：“启用”要勾选，“开始日期”不能填已过期的时间（例如现在是 2026-09-29，却填了 2024-01-01）
MySQL 用 EVENT 调度，但 event_scheduler 必须开
MySQL 没有 Agent，靠的是内置的 event_scheduler 线程。默认常处于 OFF 状态，不手动开，建了事件也永远不会执行。
- 先确认并开启：运行
SET GLOBAL event_scheduler = ON;；若要永久生效，还得在my.cnf的[mysqld]下加event_scheduler=ON - 用户必须有
EVENT权限：GRANT EVENT ON *.* TO 'your_user'@'%'; - 创建事件时，
STARTS和ENDS时间要用CURRENT_DATE或CURRENT_TIMESTAMP计算，避免硬写字符串（如'2019-06-12 23:06:00'容易过期失效） - 清空表优先用
TRUNCATE TABLE而非DELETE FROM，前者不走事务日志、更快，且重置自增 ID
跨库/跨实例场景下，别依赖当前上下文
无论是 SQL Server Agent 还是 MySQL EVENT，执行环境都不等于你日常开发时连的那个库。它们默认可能落在 master 或 mysql 库，而你的存储过程在 FinanceDB 或 log_archive 里。
- SQL Server 中，作业步骤里写三段式调用最稳：
EXEC [FinanceDB].[dbo].[DailyInvoiceCalc]，再配合下拉菜单选对数据库 - MySQL 中，事件体里直接
CALL FinanceDB.DailyInvoiceCalc();即可，无需USE FinanceDB（EVENT 不支持 USE） - 如果存储过程有输出参数或返回值，Agent 和 EVENT 都不捕获——结果验证只能靠日志表插入、邮件通知或查
msdb.dbo.sysjobhistory/information_schema.EVENTS
最容易被忽略的点是权限链和时区：SQL Server Agent 若用 Windows 账户运行，该账户得有“作为服务登录”权限；MySQL 的 @@global.time_zone 若是 SYSTEM，而系统时区没设对，事件可能在你意料之外的时间触发。这两处不检查，任务看似配好了，实则静默失败。
