SQL Server 定时需启用 SQL Server Agent 服务并配置权限，作业步骤中数据库须选对且命令为 EXEC 存储过程名；MySQL 需开启 event_scheduler 并设未来 STARTS 时间，事件名避免与存储过程重名，存储过程内须处理空值、异常及重复插入，并为报表表建立索引与分区。
SQL Server 用代理作业定时调用存储过程
SQL Server 自身不提供类似 MySQL EVENT 的原生定时机制，必须依赖 SQL Server Agent。没启用 Agent，EXEC 再多次也只会手动跑一次——这不是自动化。
常见错误现象：作业创建后从不执行，或只执行一次就停；检查“SQL Server Agent”服务是否已启动（Windows 服务里找），且运行账户有足够权限（至少对目标数据库有 db_datareader 和执行存储过程的权限）。
- 作业步骤中“数据库”下拉框必须选对——不是当前连接的库，而是存储过程所在的库
- 命令写成
EXEC Pr_daily_report即可，不用加USE [db_name]；加了反而可能因上下文切换失败 - 计划时间设为“每天 07:00”，但要注意服务器时区；若服务器在 UTC+8，而业务要求北京时间早 7 点，那就直接填
07:00，别自己换算
MySQL 开启 event_scheduler 并创建事件
MySQL 的定时能力靠 event_scheduler，它默认是 OFF。光建好存储过程、写好 CREATE EVENT 语句，不打开调度器，事件永远不会触发。
执行前先确认：SHOW VARIABLES LIKE 'event_scheduler'; 返回 ON 才算生效。如果返回 OFF，必须用管理员权限执行：SET GLOBAL event_scheduler = ON;
-
STARTS时间必须是未来时间，比如今天是 2026-06-23，就不能设STARTS '2026-06-22 00:00:00'，否则事件状态会变成SLAVESIDE_DISABLED - 事件名不能和已有存储过程重名，否则
SHOW EVENTS里看不到；建议统一加前缀，如evt_daily_report - 事件体里尽量用
CURDATE()而非NOW()，避免跨日临界点（比如 23:59:59 插入的数据被算进第二天）
存储过程内部必须处理空数据与异常边界
报表类存储过程最常崩在“查不到数据”的瞬间。比如 SELECT ... INTO @var FROM ... WHERE date = CURDATE()，若当天没订单，@var 就是 NULL，后续计算可能全错，甚至导致整个事务回滚。
不要依赖应用层兜底——定时任务没人盯着控制台。所有输出参数、INSERT 目标表字段、聚合结果都得显式处理空值。
- 用
COALESCE(SUM(amount), 0)替代裸SUM(amount) - 插入汇总表前，先
IF NOT EXISTS (SELECT 1 FROM daily_summary WHERE report_date = CURDATE()) THEN ...防重复 - 关键步骤后加
IF @@ERROR 0 BEGIN INSERT INTO error_log (...) VALUES (...); RETURN; END
报表数据写入目标表前要确认索引与分区策略
日报表每天追加一条，看似简单，但半年后 daily_summary 表超百万行，SELECT * FROM daily_summary ORDER BY report_date DESC LIMIT 10 就开始变慢——因为缺索引；更糟的是，如果没做分区，DELETE FROM daily_summary WHERE report_date 会锁表十几秒。
别等出问题再补。建表时就该定下规则：
-
report_date字段必须建聚集索引（SQL Server）或主键（MySQL），这是最常用查询条件 - 超过一年的数据考虑按月分区（SQL Server）或按年分表（MySQL），删除旧数据用
DROP PARTITION或DROP TABLE，快且不锁表 - 避免在存储过程中用
SELECT ... INTO #temp做中间计算——临时表没统计信息，执行计划容易劣化
实际部署时，最容易被忽略的是权限与时间精度。Agent 作业用的服务账户、MySQL event 的 DEFINER 用户、存储过程里访问的视图或表——每个环节的权限链都要断点验证；而“每日”这个概念，在跨时区系统、夏令时切换、或凌晨批处理窗口重叠时，CURDATE() 和 GETDATE() 的毫秒级差异，可能让某天报表漏掉最后三分钟数据。
