怎样利用MySQL存储过程定期清理数据库中的过期冗余数据？-mysql教程-PHP中文网

event才是mysql中实现定时执行的机制，存储过程仅在被调用时运行；需启用event_scheduler并创建event才能定时触发，云数据库常禁用此功能，须改用外部crontab调用。

怎样利用mysql存储过程定期清理数据库中的过期冗余数据？

存储过程本身不“定时”，EVENT 才是触发器

很多人误以为写个存储过程就能自动跑，其实存储过程只是被调用时才执行；真正实现“定期”的，是 MySQL 的 EVENT 调度器。它像一个闹钟，到点就唤起你写的存储过程。如果只建了存储过程但没配 EVENT，那它永远也不会动。

常见错误现象：执行 CREATE EVENT 报 ERROR 1541: Event scheduler is not running 或 ERROR 1547: Event execution time is in the past——这基本等于调度器根本没开，别急着改 SQL，先查状态。

查是否启用：SHOW VARIABLES LIKE 'event_scheduler';，返回 OFF 就得开
临时启用（重启失效）：SET GLOBAL event_scheduler = ON;
永久启用：在 my.cnf 的 [mysqld] 段加 event_scheduler = ON，然后重启 MySQL
云数据库（如阿里云 RDS）通常禁用该变量，此时只能放弃 EVENT，改用外部 crontab 调 CALL

存储过程里 DELETE 必须分批 + 限流 + 索引校验

直接写 DELETE FROM logs WHERE created_at 是高危操作。千万级表上这么干，轻则锁表几十秒，重则触发 <code>Lock wait timeout exceeded，业务写入全卡住。

安全做法是在存储过程中用循环控制每次删多少、隔多久再删：

必须加 LIMIT 10000（别超 5 万），否则 InnoDB 可能升级锁粒度
每次删完加 DO SLEEP(0.1)，让出 IO 和 CPU 资源，降低主从延迟风险
删前务必确认 created_at 字段有索引，否则 LIMIT 也救不了全表扫描
别用 TRUNCATE TABLE：它不能带 WHERE，也不走事务，删错了没法回滚

示例关键片段：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

DELIMITER //
CREATE PROCEDURE clean_old_logs()
BEGIN
  DECLARE row_count INT DEFAULT 1;
  WHILE row_count > 0 DO
    DELETE FROM operation_log 
      WHERE create_time <h3>EVENT 创建时时间表达式和权限最容易踩坑</h3><p><code>CREATE EVENT</code> 语法看着简单，但两处细节错一个就静默失败或错时执行：</p>

STARTS 后必须用 CURRENT_TIMESTAMP，不是 NOW() —— 后者在事件定义时刻就被固化，下次触发不会更新，结果可能永远不执行
EVERY 单位必须是单数：EVERY 1 DAY ✅，EVERY 1 DAYS ❌（报错 ERROR 1064）
执行事件的账号必须有 EVENT 权限：GRANT EVENT ON *.* TO 'user'@'host';，普通应用账号通常没有
事件体中禁止出现子查询、临时表、非确定性函数（如 RAND()），否则创建失败

推荐写法（每天凌晨 0 点执行）：

CREATE EVENT IF NOT EXISTS daily_clean_logs
ON SCHEDULE EVERY 1 DAY 
STARTS CURRENT_TIMESTAMP + INTERVAL (86400 - HOUR(CURRENT_TIME)*3600 - MINUTE(CURRENT_TIME)*60 - SECOND(CURRENT_TIME)) SECOND
ON COMPLETION PRESERVE ENABLE
DO CALL clean_old_logs();