应避免在存储过程中使用游标逐行更新，而应采用集合操作（如IN、JOIN）配合临时表批量处理，并分批次提交以控制锁时间和事务大小，同时确保WHERE条件字段有索引。
存储过程里别用游标逐行更新
直接在存储过程中写 CURSOR + FETCH 循环，本质还是单条 UPDATE，性能不会比应用层循环好多少。InnoDB 行锁会持续到事务结束，10 万行就等于锁 10 万次、事务日志暴涨、undo 空间吃紧，还容易触发 Lock wait timeout exceeded。
真正有效的做法是：把逻辑“推给 SQL 引擎”，用集合操作替代循环。比如要批量激活一批用户：
- 错的写法：
UPDATE users SET status = 1 WHERE id = @user_id;在循环里反复执行 - 对的写法：
UPDATE users SET status = 1 WHERE id IN (SELECT id FROM temp_batch WHERE processed = 0);
前提是先建好临时表或内存表存目标 ID，再一次性 JOIN 或 IN 更新。游标只在极少数必须依赖前序结果的场景下才考虑，且得配合 COMMIT 分批提交。
临时表 + JOIN 是海量更新的主力方案
当你要更新百万级数据，且新值来自复杂计算（比如关联订单表算总消费额），硬拼 CASE WHEN 不现实——SQL 过长会超 max_allowed_packet，解析也慢。这时该用临时表：
- 用
CREATE TEMPORARY TABLE temp_update (id BIGINT PRIMARY KEY, new_value DECIMAL(10,2)) ENGINE=MEMORY;建内存临时表（快、不落盘） -
INSERT INTO temp_update SELECT u.id, o.total * 0.9 FROM users u JOIN orders o ON u.id = o.user_id WHERE ...;一次性算好待更新值 -
UPDATE users u JOIN temp_update t ON u.id = t.id SET u.score = t.new_value;单条 JOIN 完成更新
注意：ENGINE=MEMORY 适合中小批量；超 50 万行建议用 InnoDB 临时表，避免内存溢出；JOIN 条件字段（如 u.id）必须有索引，否则变全表扫描。
分批次控制事务大小和锁时间
哪怕用了临时表，一次性更新 200 万行仍可能卡住主库、拖慢从库复制。必须分批，但别在存储过程里写死循环次数——用 LIMIT + ROW_COUNT() 更可靠：
REPEAT UPDATE users u JOIN temp_update t ON u.id = t.id SET u.status = 2 LIMIT 5000; UNTIL ROW_COUNT() = 0 END REPEAT;- 每次只改 5000 行，
ROW_COUNT()返回实际影响行数，自动终止 - 每批隐式提交（autocommit=1）或显式加
COMMIT，释放行锁，避免长时间阻塞其他业务
批次大小不是越大越好：5000 是常见起点，若观察到 innodb_row_lock_time_avg 上升或 SHOW PROCESSLIST 出现 Waiting for table metadata lock，就该调小到 1000 或 2000。
参数和索引漏掉一个，性能直接打五折
存储过程本身不解决底层瓶颈。以下三点常被忽略，却决定成败：
-
WHERE条件字段没索引？比如UPDATE ... WHERE status = 0 AND created_at ，必须给 <code>(status, created_at)建联合索引，否则扫全表 -
innodb_flush_log_at_trx_commit设为2（非1）可大幅减少刷盘，但牺牲部分持久性——批量更新场景通常可接受 - 临时表字段类型要和主表严格一致，比如主表
id是BIGINT UNSIGNED，临时表也得定义成一样，否则 JOIN 时隐式转换导致索引失效
最后提醒：存储过程适合封装固定逻辑（如每月跑一次的积分重算），但调试困难、版本难管理。上线前务必在测试库用 EXPLAIN FORMAT=JSON 看执行计划，确认走了索引、没临时表、没 filesort——这些细节比语法本身更关键。
