游标在MySQL中性能极差，因其逐行处理、无法索引下推、锁持有时间长；应优先用集合操作替代，必须使用时需严格遵循索引优化、分批提交、避免嵌套等硬约束。
游标在MySQL存储过程中处理大数据量时，性能通常很差——这不是配置问题，而是设计本质决定的。它逐行交互、无法利用索引下推、锁持有时间长，几十万行就可能卡住整个表。
为什么游标在MySQL里特别慢
MySQL游标是只读、单向、无缓冲的，每次FETCH都触发一次内部行获取+变量赋值+控制流判断，底层相当于对每行执行一次微型查询。更关键的是：它默认在REPEAT或LOOP中隐式维持事务边界，若未显式COMMIT，整个循环期间表锁或行锁持续存在。
- 每次
FETCH都会增加网络往返模拟开销（即使本地执行，也走完整SQL执行路径） - 无法使用
WHERE下推或LIMIT跳过中间数据，必须全扫描结果集才能定位“下一行” - 声明时的
SELECT语句若没走索引，游标打开阶段就会卡住，且错误不报在OPEN而是在第一次FETCH -
DECLARE CONTINUE HANDLER FOR NOT FOUND仅捕获“无数据”，不捕获超时、锁等待、主从延迟导致的临时阻塞
能不用游标就别用：优先集合操作替代方案
95% 的游标使用场景其实可以用一条UPDATE、INSERT ... SELECT或带窗口函数的DELETE代替。比如要给活跃用户发通知并标记已处理，别写游标循环SELECT再UPDATE，直接：
UPDATE users SET notify_status = 'sent', updated_at = NOW() WHERE status = 'active' AND notify_status = 'pending' LIMIT 1000;
配合外部脚本分页调用，比游标快一个数量级。其他可行替代方式包括：
- 用
CREATE TEMPORARY TABLE预存目标ID，再用JOIN批量更新，避免重复计算条件 - 对需复杂逻辑的字段，先用
SELECT ... INTO OUTFILE导出，用Python/Go做转换后再LOAD DATA INFILE - 用
EVENT调度器分时段执行小批量UPDATE，避开业务高峰 - 若必须依赖前一行结果（如累计求和），改用变量赋值：
@sum := @sum + value，在单条SELECT中完成
非用不可时：最小化游标伤害的硬约束
如果业务强依赖逐行判断（例如调用外部HTTP接口、触发审计日志、状态机流转），游标无法绕过，那就必须加硬约束止损：
- 声明游标前，务必用
EXPLAIN确认其SELECT走索引，且rows预估值合理；避免SELECT *，只选必要字段 - 在循环体内禁止任何
SELECT子查询、禁止CALL其他存储过程（会嵌套事务）、禁止SLEEP()类阻塞操作 - 每处理
100行后主动COMMIT，并用SELECT ROW_COUNT()校验实际更新数，防止部分失败静默 - 用
READ COMMITTED隔离级别启动存储过程，减少锁等待；避免在REPEAT外再套BEGIN ... END事务块 - 游标变量名加前缀如
cur_batch_id，和普通变量v_id区分开，防止FETCH INTO错位赋值（这是最常被忽略的运行时错误）
游标嵌套几乎总是错的
嵌套游标（外层查A表，内层对每个A查B表）会让时间复杂度从O(n)变成O(n×m)，且MySQL不支持游标参数化传入，只能靠变量中转，极易出现v1值未及时刷新导致内层查错数据。真实案例中，嵌套游标处理10万行平均耗时23分钟，而改用LEFT JOIN + INSERT ... SELECT仅需6秒。
真正需要关联处理时，应先用CREATE TEMPORARY TABLE tmp_join AS SELECT ... JOIN ...落地中间结果，再对临时表单层游标遍历——至少把N×M降为N+M。
