应避免使用游标和WHILE循环，因其逐行处理导致性能极低；优先采用UPDATE JOIN、CASE WHEN批量赋值、临时表JOIN等集合操作替代，同时确保索引优化与查询精简。
能不用循环就别用——95% 的“必须循环”场景，其实一条 SQL 就能解决。 游标和 WHILE 循环在 MySQL 存储过程中天然低效，不是写法问题，是执行模型决定的：逐行 fetch、逐行 parse、逐行执行、逐行加锁。真正要优化的，不是怎么把循环写得更快，而是怎么把它整个删掉。
为什么游标循环慢到不可接受
MySQL 游标本质是服务器端结果集的单向指针，每次 FETCH 都触发一次内部行缓冲、类型转换和权限检查；更关键的是，它强制把集合操作降维成 N 次单行事务上下文切换。哪怕只是 UPDATE users SET status = 1 WHERE id = ? 这种简单语句，在循环里跑 10 万次，也会比 UPDATE users SET status = 1 WHERE id IN (…) 慢 20 倍以上——这还不算锁等待和日志刷盘放大效应。
- 全表扫描风险高：游标
DECLARE cur CURSOR FOR SELECT …若没走索引，一开就扫全表 - 无法利用查询缓存：游标内动态语句（如拼接条件）基本绕过缓存
- 事务膨胀：默认自动提交关着，10 万次更新可能撑爆
innodb_log_file_size - 监控盲区：慢查询日志只记存储过程调用入口，不记录游标内部耗时
用 UPDATE JOIN 替代逐行更新
这是最常用也最有效的替换方式，适用于“根据另一张表/子集条件更新当前表”的典型场景。比如原逻辑是遍历订单找用户，再更新用户积分：
-- 错误示范（循环） DECLARE done INT DEFAULT FALSE; DECLARE order_id INT; DECLARE cur CURSOR FOR SELECT id FROM orders WHERE created_at >= '2026-05-01'; ... FETCH cur INTO order_id; UPDATE users u JOIN orders o ON u.id = o.user_id SET u.points = u.points + o.amount WHERE o.id = order_id;
直接改写为：
UPDATE users u JOIN orders o ON u.id = o.user_id SET u.points = u.points + o.amount WHERE o.created_at >= '2026-05-01';
- 确保
orders.created_at和orders.user_id有联合索引，例如INDEX idx_created_user (created_at, user_id) - 如果更新量极大（如百万级），加
LIMIT 10000分批执行，避免长事务阻塞 DDL - 不要用
SELECT * FROM …构造中间结果集再循环——那只是把游标换了个马甲
CASE WHEN + 主键 IN 列表实现条件批量赋值
当不同行需更新为不同值（比如按城市设置运费、按等级调整折扣），CASE WHEN 是比循环更安全可控的选择：
UPDATE products SET price = CASE id WHEN 101 THEN 99.9 WHEN 102 THEN 129.5 WHEN 103 THEN 88.0 ELSE price END WHERE id IN (101, 102, 103);
-
WHERE id IN (…)必须带，否则全表扫描+无意义 CASE 计算 - IN 列表长度建议控制在 1000 以内；超量时拆成多个语句或改用临时表
JOIN - 若值来自另一张配置表，优先走
UPDATE t1 JOIN t2 ON … SET t1.x = t2.y，而非先查出再拼 CASE
临时表 + 批量 JOIN 是复杂逻辑的兜底方案
只有当每行处理逻辑涉及多步计算、跨库查参、或依赖上一行结果时，才考虑临时表。但注意：临时表本身不是目的，是为把“行级状态依赖”转化为“集合间关系”服务的。
-- 把需要处理的 ID 先捞进内存表 CREATE TEMPORARY TABLE temp_targets ( id BIGINT PRIMARY KEY, calc_value DECIMAL(10,2) ) ENGINE = MEMORY; <p>INSERT INTO temp_targets SELECT id, base_price * IF(category = 'A', 1.2, 0.9) FROM products WHERE updated_at < NOW() - INTERVAL 1 DAY;</p><p>-- 一次性更新 UPDATE products p JOIN temp_targets t ON p.id = t.id SET p.price = t.calc_value;
- 用
ENGINE = MEMORY避免磁盘 IO，但注意max_heap_table_size限制 - 临时表字段尽量精简，只保留 JOIN 键和最终要写的字段
- 千万别在循环里反复
INSERT INTO temp_targets——又回到原点
真正难的从来不是写出能跑的循环，而是识别出哪部分逻辑其实根本不需要逐行发生。索引缺失、SELECT *、嵌套子查询、没加 WHERE 的 JOIN……这些才是让“批量改写”失败的隐形门槛。动手前先 EXPLAIN 原始查询，比调游标参数实在得多。
