MySQL存储过程中应使用WHILE或REPEAT循环实现分批删除，每次LIMIT 5000行并显式COMMIT，确保WHERE走索引、避免大表JOIN、控制事务大小防超时与锁表，EVENT中不可直接写LIMIT需调用存储过程，删后建议ANALYZE TABLE更新统计信息。
MySQL存储过程里怎么写循环删除逻辑
直接用 WHILE 或 REPEAT 是最稳妥的方式，FOR 循环在 MySQL 存储过程中根本不存在（8.0 也不支持），别被某些博客误导。重点不是“能不能循环”，而是“删得安全不锁表、不爆内存、不超时”。
常见错误现象：ERROR 1317 (70100): Query execution was interrupted —— 一次删太多行，触发了 max_execution_time；或者事务太大，innodb_log_file_size 不够，导致回滚段撑爆。
- 每次只删固定行数（比如
5000行），用LIMIT控制，配合ROW_COUNT()判断是否还有数据可删 - 显式加
COMMIT，别依赖自动提交——存储过程默认在会话级开启事务，不提交会导致锁一直挂着 - WHERE 条件必须走索引，否则每次循环都全表扫描，越删越慢
- 避免在循环体内查大表或做复杂 JOIN，容易把临时表空间打满
DELIMITER $$
CREATE PROCEDURE clean_old_logs()
BEGIN
DECLARE done INT DEFAULT FALSE;
DECLARE batch_size INT DEFAULT 5000;
REPEAT
DELETE FROM logs WHERE created_at < DATE_SUB(NOW(), INTERVAL 90 DAY) LIMIT batch_size;
IF ROW_COUNT() = 0 THEN
SET done = TRUE;
ELSE
COMMIT; -- 显式提交释放锁和日志空间
END IF;
UNTIL done END REPEAT;
END$$
DELIMITER ;怎么让存储过程被定时执行（非事件调度器）
MySQL 的 EVENT 调度器在很多生产环境是关闭的（event_scheduler=OFF），尤其云数据库（如阿里云 RDS、腾讯云 CDB）默认禁用且无法开启。这时候靠外部调度更可靠。
使用场景：你有 Linux 服务器权限，或能部署轻量脚本；不想依赖 MySQL 内部状态，避免因 MySQL 重启导致定时任务丢失。
- 用系统
cron调mysql命令行工具执行存储过程，例如：mysql -uuser -ppass db_name -e "CALL clean_old_logs();" - 注意密码明文风险：改用配置文件方式（
~/.my.cnf）并设chmod 600，别放进 crontab 命令里 - 加
2>/dev/null避免失败时发邮件，但建议先手动跑通再加重定向 - 如果删的是关键业务表，cron 命令前加时间判断，避开高峰期，比如：
[[ $(date +\%H) =~ ^[0-5]$ ]] && mysql ...
为什么不能直接在 EVENT 里写 DELETE … LIMIT
因为 EVENT 本身不支持 LIMIT 子句（语法报错：ERROR 1064 (42000)），哪怕包在存储过程中调用也行，但 EVENT 定义里直接写就不行。这是 MySQL 的硬限制，不是权限或版本问题。
另一个坑：EVENT 默认在定义者上下文执行，如果存储过程用了 DEFINER 且该用户权限不足，即使 EVENT 激活了也静默失败，查 mysql.event 表或错误日志才能发现。
- 务必用
SHOW EVENTS确认状态是ENABLED，且Last_executed在更新 - EVENT 中调用存储过程时，确保该过程对 EVENT 定义用户可见（
GRANT EXECUTE ON PROCEDURE db_name.proc_name TO 'definer_user'@'%'） - 别设太短的间隔（如
EVERY 1 SECOND），MySQL EVENT 最小粒度其实是 1 分钟，更短会四舍五入或报错
删完数据后要不要 ANALYZE TABLE
要，但不是每次都必须。InnoDB 在大量删除后，统计信息可能滞后，导致后续查询执行计划变差（比如该走索引却走了全表扫描）。
性能影响：ANALYZE TABLE 会加 MDL 读锁，阻塞 DDL，但不阻塞 DML；对大表耗时明显，特别是没 SSD 的机器。
- 如果表数据量 ANALYZE TABLE logs; 是划算的
- 如果表超千万，考虑改用采样方式：
ANALYZE TABLE logs UPDATE HISTOGRAM ON created_at WITH 16 BUCKETS;（MySQL 8.0+） - 云数据库注意：RDS 的
ANALYZE可能被后台自动任务抢占资源，观察information_schema.INNODB_METRICS中的dml_reads波动
真正容易被忽略的是：删完不提交 + 不 analyze + 不看执行计划，三者叠加，过两天就发现某个报表接口慢了三倍，但没人想到是三个月前那个凌晨删日志的存储过程惹的祸。
