游标慢的根本原因是执行模型缺陷：每次fetch触发完整sql流程，不走存储引擎批量通道，导致n次小查询叠加；应改用临时表+join批量处理替代。
游标慢的根本原因不是“写法”，而是执行模型
MySQL游标本质是客户端模拟——每次 FETCH 都触发一次完整 SQL 执行流程：解析、优化、执行、构造单行结果集、网络打包。它不走存储引擎原生批量通道，CPU 和锁开销远高于集合操作。你看到的“慢”，其实是 N 次小查询叠加的必然结果，不是某条语句没加索引的问题。
常见错误现象包括：CPU 飙高、SHOW PROCESSLIST 中大量 Sleep 或 Locked 状态、performance_schema.events_statements_history_long 里同名游标反复出现不同 PLAN_EXPLAIN。
- 不要在游标循环里做
SELECT ... INTO或UPDATE单行操作 - 避免用游标遍历大表（如
SELECT id FROM orders WHERE created_at >= '2026-05-01'）再逐条关联更新 - 即使加了
READ COMMITTED和LOCK IN SHARE MODE，也只缓解锁问题，不解决执行模型缺陷
用临时表 + JOIN 替代游标遍历
把“逐行处理”转成“批量关联”，是唯一真正有效的提速路径。核心是让优化器一次性规划整个数据流，而不是重复生成 N 个执行计划。
典型场景：根据一批订单 ID 更新对应用户积分。
- 先建带主键的临时表：
CREATE TEMPORARY TABLE tmp_order_ids (id BIGINT PRIMARY KEY); - 批量插入 ID：
INSERT INTO tmp_order_ids SELECT id FROM orders WHERE created_at >= '2026-05-01'; - 一次 JOIN 完成更新：
UPDATE users u JOIN orders o ON u.id = o.user_id JOIN tmp_order_ids t ON o.id = t.id SET u.points = u.points + o.amount;
注意：临时表必须有主键或唯一索引，否则 JOIN 会退化为嵌套循环，比游标还慢。
必须用游标时的底线控制
某些逻辑确实无法完全平铺（比如需要基于前一行结果动态计算下一行参数），此时只能接受游标开销，但必须设硬性约束防止失控。
- 限制游标结果集大小：
SELECT id FROM orders WHERE created_at >= '2026-05-01' LIMIT 1000，超量改分批调用 - 显式声明隔离级别：
DECLARE cur CURSOR FOR SELECT ... LOCK IN SHARE MODE;，避免间隙锁扩散 - 禁用自动提交并在游标外显式控制事务：
START TRANSACTION; ... COMMIT;，防止每行都隐式提交加重日志压力 - 删除无意义中间查询：任何没接
INTO、没进INSERT SELECT、也没用于IF判断的SELECT，都是内存和缓冲区浪费
版本与缓存陷阱：游标慢可能根本不是游标的问题
MySQL 5.7.21 之前版本根本不支持存储过程缓存，每次 CALL 都重新解析游标定义。如果 SELECT VERSION() 返回 5.6.42 或 5.7.18，别优化游标，先升级。
即使版本达标，也要验证是否真命中缓存：SELECT DIGEST_TEXT FROM performance_schema.events_statements_history_long WHERE DIGEST_TEXT LIKE '%DECLARE%CURSOR%FOR%'; 如果每次调用 DIGEST 不同，大概率是参数类型不一致（比如声明 IN p_id INT，却传入字符串 '123'），导致隐式转换后执行计划失效。
真正难察觉的点在于：游标本身不报错，参数类型错配也不会中断执行，只是默默放弃索引、全表扫描、缓存失效——所有这些，都会被归因到“游标慢”。
