WHILE循环是SQL存储过程的性能瓶颈而非解法，它将集合操作降维为串行单行事务，导致CPU单核饱和、日志暴涨、锁等待激增；必须仅在无法转为集合操作时慎用，并严格遵循临时表、计数器上限、错误检查、分片控制等约束。
WHILE循环在SQL存储过程中不是性能瓶颈的“解法”，而是问题本身——它把本可并行、批量执行的集合操作，硬生生降维成串行单行事务，CPU利用率卡死单核，日志暴涨，锁等待激增。
WHILE循环天然破坏数据库执行模型
MySQL和SQL Server的执行引擎都为集合操作优化：一次解析、一次计划、批量数据流。WHILE一介入，就强制切换成N次独立上下文：每次FETCH或条件判断都要重新校验权限、重编译语句（尤其含动态SQL时）、触发行级锁和日志刷盘。哪怕只是UPDATE users SET status = 1 WHERE id = ?，跑10万次比UPDATE users SET status = 1 WHERE id IN (…)慢20倍以上。
- MySQL游标每次
FETCH都走完整服务器端结果集缓冲流程，类型转换+权限检查+行缓存分配 - SQL Server中
WHILE若直接查基表（不走临时表），每轮SELECT MIN(id)都会引发全表扫描或索引查找+锁等待 - 二者均无法利用查询缓存：循环内拼接的
WHERE条件基本绕过缓存机制
真正容易被忽略的隐性开销
开发者常只盯住“循环体执行时间”，却漏掉三类沉默杀手：
-
innodb_log_file_size撑爆：MySQL默认自动提交关闭，10万次更新可能让事务日志写满，报LOG FULL - 监控盲区：慢查询日志只记
CALL proc_name()入口，不记录循环内部哪一轮卡住 - 锁生命周期失控：若循环里有
SELECT ... FOR UPDATE，锁会持续到整个WHILE块结束，而非单行——除非手动COMMIT，否则极易引发死锁或阻塞其他会话
WHILE不是不能用，而是必须满足严苛前提
只有当业务逻辑确实无法转成集合操作时（例如：每批需调用sp_executesql动态构造不同SQL、或依赖上一批处理结果生成下一批参数），才考虑WHILE，且必须配套以下约束：
- 数据必须先
SELECT ... INTO #temp进临时表，禁止在循环体内反复查原表 - 必须用计数器+上限双保险：
DECLARE i INT DEFAULT 0; DECLARE max_iter INT DEFAULT 10000;，条件写成WHILE i < max_iter，且SET i = i + 1放在循环末尾不可跳过的位置 - 每批处理后加
IF @@ERROR != 0 BEGIN ROLLBACK; RETURN; END，别指望外层TRY...CATCH能兜住循环内错误 - 分片大小设为5000~10000行：太小导致循环次数爆炸；太大则单事务日志压力过大
最常被跳过的动作是：循环跑完后不验证@i是否真等于预期处理行数——如果它停在max_iter，说明逻辑被截断了，但过程仍显示Query OK。
