MySQL存储过程循环查询不增加连接数，因全程复用单个连接；真正消耗资源的是重复SQL解析、游标行拷贝、隐式事务日志刷盘及无退出条件导致的CPU独占。
MySQL存储过程里循环查询本身不产生“连接开销”，真正吃资源的是反复执行SQL、游标管理、事务膨胀和未设退出条件的死循环——连接数不会因此增加，但单个连接的CPU、IO、内存会飙高。
为什么“循环查询”不等于“多连接”
存储过程在单个数据库连接内执行，FOR IN（实际是 CURSOR + LOOP）或 WHILE 都复用同一连接。所谓“连接开销”其实是误传，真实问题是：
- 每次
SELECT触发一次语句解析 + 执行 + 结果集返回，即使没网络传输，引擎层开销也累加 - 游标
FETCH每次都要定位、拷贝行数据，大结果集下内存占用明显上升 - 若循环体内隐式开启事务（如含
UPDATE），每轮都写 binlog/redo log，日志刷盘压力陡增 - 没设
max_iter或退出条件的WHILE，会让该连接持续占满一个 CPU 核心，SHOW PROCESSLIST状态卡在Executing
如何让循环体内的查询不拖垮单连接
核心思路：把“循环做N次小查询”改成“一次查完N条所需数据”，再本地处理。不是靠减少连接，而是砍掉重复执行路径。
- 用
JOIN替代循环内SELECT ... WHERE id = ?：比如原逻辑是遍历订单ID查用户信息，直接写成SELECT o.id, u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = 'pending' - 用
IN (subquery)或临时表承接中间结果：若必须分批（如超 1000 行），先CREATE TEMPORARY TABLE batch_ids (id INT)，批量INSERT后再JOIN查询 - 禁用循环内自动提交：显式用
START TRANSACTION包裹整个循环，或干脆关掉autocommit，避免每轮都刷日志 - 游标只读且声明为
READ ONLY：减少锁和一致性读开销，例如DECLARE cur CURSOR FOR SELECT ...前加READ ONLY
必须加的两道安全阀：计数器 + 执行时间限制
生产环境不设兜底机制的循环，等于给 MySQL 装了个定时炸弹。
- 在
WHILE循环前声明：DECLARE iter_count INT DEFAULT 0;和DECLARE max_iter INT DEFAULT 5000;，循环末尾强制SET iter_count = iter_count + 1;，开头检查IF iter_count >= max_iter THEN LEAVE main_loop; END IF; - 调用前设置会话级超时：
SET SESSION max_execution_time = 30000;（单位毫秒），MySQL 5.7.8+ 对存储过程内所有语句生效 - 别信“业务上最多就200行”，按预估上限 × 1.5 再向上取整设
max_iter；循环退出后建议加日志：比如SELECT CONCAT('Processed ', iter_count, ' rows');
最容易被忽略的一点：游标打开后忘记 CLOSE，或者异常分支没 LEAVE，会导致连接长期持有表元数据锁，后续 DDL（如 ALTER TABLE）直接被阻塞。写完务必检查所有退出路径是否覆盖 CLOSE 和 LEAVE。
