MySQL存储过程不能自动定时执行，需依赖MySQL事件调度器（EVENT）或操作系统级定时任务（如crontab）触发；前者轻量且数据库内闭环，后者兼容旧版本。
MySQL存储过程不能直接实现定时任务
MySQL本身不支持像Linux cron那样原生调度存储过程。你写的CREATE PROCEDURE只是定义逻辑，不会自动每天执行——必须配合外部调度器或MySQL事件（EVENT）才能触发。
真正可行的路径只有两条：启用MySQL事件调度器 + 创建EVENT，或者用操作系统级定时任务（如crontab）调用mysql -e "CALL reset_counter();"。前者更轻量、数据库内闭环；后者依赖外部环境，但兼容旧版本MySQL（
启用事件调度器并创建每日重置EVENT
MySQL事件默认是关闭的，必须显式开启，否则CREATE EVENT会静默失败或报错ERROR 1477 (HY000): The event scheduler is not running。
- 检查状态：
SHOW VARIABLES LIKE 'event_scheduler';—— 返回OFF需启用 - 临时启用（重启失效）：
SET GLOBAL event_scheduler = ON; - 永久启用：在
my.cnf（Linux）或my.ini（Windows）的[mysqld]段加一行event_scheduler=ON，然后重启MySQL - 创建EVENT示例（每天凌晨2点重置
counter字段）：CREATE EVENT reset_daily_counter ON SCHEDULE EVERY 1 DAY STARTS TIMESTAMP(CURDATE() + INTERVAL 2 HOUR) DO UPDATE stats_table SET counter = 0 WHERE id = 1;
注意STARTS必须是未来时间点，如果写成CURDATE()当天已过2点，事件会跳过首日执行；用TIMESTAMP(CURDATE() + INTERVAL 2 HOUR)可确保从明天开始生效。
存储过程里别硬编码表名和条件
如果坚持用存储过程封装重置逻辑（比如要复用、加日志、多表联动），就别把stats_table或id = 1写死——这类硬编码会让过程无法跨环境迁移，也难测试。
- 用IN参数接收表名？不行。
EXECUTE IMMEDIATE在MySQL中叫PREPARE+EXECUTE，但表名不能参数化，只能拼字符串（有SQL注入风险） - 安全做法：只参数化值，不参数化对象名。例如
IN p_target_id INT传入ID，UPDATE语句保持静态 - 如果真要动态表名，必须用
CONCAT()拼接SQL字符串+PREPARE，且仅限可信上下文（如DBA运维脚本），生产环境慎用 - 示例安全写法：
DELIMITER $$ CREATE PROCEDURE reset_counter(IN p_id INT) BEGIN UPDATE stats_table SET counter = 0 WHERE id = p_id; END$$ DELIMITER ;
EVENT和存储过程组合使用时的权限与错误捕获
EVENT以定义者（DEFINER）权限运行，不是调用者权限。如果DEFINER = 'admin'@'%'但该用户没有UPDATE权限，事件会静默失败——查不到错误，计数器也不重置。
- 创建EVENT时显式指定DEFINER：
CREATE DEFINER = 'your_user'@'localhost' EVENT ...，确保该用户有对应表的UPDATE权限 - MySQL事件不支持
TRY...CATCH，出错日志只记在错误日志（mysqld.err）里，可通过SELECT * FROM mysql.event;确认状态，status字段为ENABLED≠正在运行 - 调试技巧：先手动执行
CALL reset_counter(1);验证逻辑，再建EVENT；建好后等几分钟，查information_schema.EVENTS里的LAST_EXECUTED是否更新
最常被忽略的是事件时区——如果服务器时区是UTC，而你想按北京时间（UTC+8）每天执行，得在ON SCHEDULE里换算，或统一设MySQL时区为SYSTEM并确保系统时钟正确。
