存储过程循环不增加连接数但会耗尽单个连接cpu，因每次循环触发sql解析、执行、结果拷贝、redo/binlog刷盘及死循环霸占核心；应改用集合操作替代循环，加计数器与执行时间双重防护，并优化游标与事务配置。
存储过程循环不增加连接数，但会吃光单个连接的CPU
MySQL存储过程里的WHILE或游标循环，全程复用同一个数据库连接，根本不会产生“连接开销”。真正让CPU飙到100%的是：每次循环都触发一次SQL解析 + 执行 + 结果集拷贝；游标FETCH逐行读取时内存持续拷贝；隐式事务每轮都刷redo log和binlog；以及没设退出条件的死循环直接霸占一个CPU核心。你看到SHOW PROCESSLIST里状态卡在Executing，基本就是这几种情况之一。
用集合操作替代循环，而不是“优化循环”
别在循环里写UPDATE users SET status = 1 WHERE id = ?再套一层FETCH——这是最典型的性能陷阱。正确做法是把N次小操作合并成1次大操作：
- 原逻辑遍历订单查用户？改写成
SELECT o.id, u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = 'pending' - 原逻辑逐行更新状态？直接
UPDATE users SET status = 1 WHERE status = 0 - 必须分批处理（比如超5000行）？先
CREATE TEMPORARY TABLE batch_ids (id INT)，批量INSERTID，再JOIN一次性处理
执行时间从O(N)降到O(1)，不是“快一点”，是量级差异。
必须加的两道安全阀：计数器 + 执行时间限制
生产环境任何没兜底的循环都是定时炸弹。哪怕业务说“最多200条”，也要按预估上限×1.5再向上取整设防护：
- 声明变量：
DECLARE iter_count INT DEFAULT 0;和DECLARE max_iter INT DEFAULT 5000; - 循环开头检查：
IF iter_count >= max_iter THEN LEAVE main_loop; END IF; - 循环末尾递增：
SET iter_count = iter_count + 1; - 调用前设会话超时：
SET SESSION max_execution_time = 30000;（MySQL 5.7.8+生效）
这两道阀缺一不可：只设max_execution_time可能因语句拆分失效；只设计数器无法防住单次查询本身卡死。
游标和事务配置细节决定实际负载
即使必须用游标，也能大幅降低开销：
- 声明时加
READ ONLY：DECLARE cur CURSOR FOR SELECT ...前面明确写READ ONLY，减少一致性读和锁开销 - 禁用循环内自动提交：
START TRANSACTION包整个循环体，或提前SET autocommit = 0，避免每轮都刷日志 - 避免在循环里做
SELECT ... INTO赋值后立刻UPDATE——这等于把一次JOIN拆成两次网络往返（虽无网络，但引擎层交互照旧）
最容易被忽略的是游标声明位置：它应该在OPEN之前就定义好，且SELECT语句本身不能含变量拼接（否则每次循环都重解析）。
