mysql 5.7中while循环天然低效，应优先用集合操作替代：如update join+case when批量打标签、int计数器生成日期序列、left join+group by替代循环累加统计，并务必为临时表添加索引。
WHILE循环在MySQL 5.7中天然低效，别试图“优化循环”，先想怎么删掉它
MySQL 5.7 的 WHILE 循环不是写法问题，而是执行模型限制：每次迭代都要重新解析 SQL、触发锁、产生临时行、调用函数（如 DATE_SUB）、甚至隐式类型转换。实测中，10 万次简单 WHILE 循环可能耗时数秒——而等价的单条 INSERT ... SELECT 通常在毫秒级。真正该花时间的，是把业务逻辑从“逐行处理”重构成“集合操作”。
用UPDATE JOIN或CASE WHEN替代循环赋值
常见场景：遍历用户表，按积分区间打标签（如“VIP”“普通”“新客”）。错误做法是 DECLARE cur_id INT; DECLARE cur_score INT; ... OPEN cur; REPEAT ... FETCH ... IF cur_score > 1000 THEN UPDATE ...。这会引发大量单行 UPDATE，锁表时间长、日志膨胀快。
正确做法是直接用批量语句：
UPDATE users u
JOIN (
SELECT id,
CASE
WHEN score >= 1000 THEN 'VIP'
WHEN score BETWEEN 100 AND 999 THEN '普通'
ELSE '新客'
END AS tag
FROM users
WHERE updated_at <p>要点：</p>
- WHERE 条件必须精准，避免全表扫描；若需限定范围，优先用索引字段（如
updated_at）而非计算字段 -
CASE WHEN在子查询中完成逻辑判断，不依赖变量状态，无竞态风险 - JOIN 后的
SET是原子更新，比循环中多次UPDATE少 90%+ 的锁开销
生成日期序列时，用INT计数器比DATE变量更稳
MySQL 5.7 不支持 WITH RECURSIVE 或 GENERATE_SERIES，但很多人用 @d := DATE_SUB(@d, INTERVAL 1 DAY) 倒推日期，结果某天 @d 变成 NULL，后续所有 DATE_SUB(NULL, ...) 全返回 NULL，循环卡死。
安全写法是用整数计数器驱动：
DELIMITER $$ CREATE PROCEDURE generate_date_series(IN start_dt DATE, IN days INT) BEGIN DECLARE i INT DEFAULT 0; DECLARE dt DATE; DROP TEMPORARY TABLE IF EXISTS tmp_dates; CREATE TEMPORARY TABLE tmp_dates (dt DATE PRIMARY KEY); <p>WHILE i 1000 THEN LEAVE loop_label; END IF; END WHILE; END$$ DELIMITER ;</p>
关键点：
- 用
INT计数器i控制循环次数，完全规避日期运算失败风险 -
tmp_dates.dt必须加PRIMARY KEY或显式INDEX(dt)，否则后续LEFT JOIN会全表扫描 - JOIN 业务表时，别写
DATE(order_time) = dt（索引失效），改用order_time >= dt AND order_time
LEFT JOIN补全+聚合必须分步，别在WHILE里累加
时间序列统计常有人在循环里做：SELECT COUNT(*) INTO @cnt FROM orders WHERE DATE(create_time) = @dt; SET total = total + @cnt;。这不仅慢，还容易因并发写入导致重复计或漏计。
应拆成三步：
- 先用
CREATE TEMPORARY TABLE tmp_result (dt DATE PRIMARY KEY, cnt INT DEFAULT 0)建结构 - 再用
INSERT INTO tmp_result SELECT d.dt, COUNT(o.id) FROM tmp_dates d LEFT JOIN orders o ON o.create_time >= d.dt AND o.create_time - 最后查
tmp_result——所有计算在单次 SQL 中完成，无变量依赖、无锁竞争
注意：TRUNCATE tmp_result 比 DELETE FROM 快，且不会触发外键检查；REPLACE INTO 在有唯一键时性能极差，严禁用于高频聚合写入。
最易被忽略的一点：临时表的索引不是“可选”，而是“必须”。哪怕只存几百行日期，没索引的 tmp_dates 在 JOIN 时仍可能让整个查询退化为 O(n×m) 复杂度。
