SQL Server中WHILE循环需手动更新驱动变量，否则易致死循环；常见陷阱包括隐式事务开销、未索引查询导致全表扫描、标量函数滥用及游标状态判断失效。
SQL Server 里 WHILE 循环的写法和常见陷阱
SQL Server 原生支持 WHILE，但它的行为和 C/Python 里的循环有本质区别：它不自动维护迭代变量、不支持 break/continue 的标准语义（得靠 IF ... BREAK 或 IF ... CONTINUE 模拟），而且每次循环都可能触发隐式事务或锁等待。
典型写法是：
DECLARE @i INT = 1;
WHILE @i <= 10
BEGIN
-- 执行逻辑，比如 INSERT 或 UPDATE
INSERT INTO logs (msg) VALUES ('loop ' + CAST(@i AS VARCHAR));
<pre class='brush:php;toolbar:false;'>SET @i = @i + 1;END
-
WHILE条件只在每次循环**开始前**判断，不会在循环体中途重检 - 必须显式用
SET或SELECT更新控制变量，漏写会导致无限循环 - 如果循环体内有
INSERT/UPDATE，且没加COMMIT或TRY...CATCH，出错时整个批处理会中断，已执行的语句不会自动回滚（除非在显式事务中）
MySQL 存储过程中怎么写等效的循环？
MySQL 不支持 WHILE 关键字直接裸用，必须配合 LOOP、REPEAT 或 WHILE 语句块，且必须声明标签（label）并用 LEAVE 跳出。
最接近传统 WHILE 的是 WHILE ... DO ... END WHILE：
DELIMITER $$
CREATE PROCEDURE loop_demo()
BEGIN
DECLARE i INT DEFAULT 1;
WHILE i <= 5 DO
INSERT INTO test_table (val) VALUES (i);
SET i = i + 1;
END WHILE;
END$$
DELIMITER ;- 必须用
DELIMITER改变语句结束符，否则分号会被解释为存储过程定义结束 -
DECLARE变量的作用域仅限当前BEGIN...END块，嵌套块中同名变量会遮蔽外层 - MySQL 的
WHILE不支持在条件中调用函数返回结果集（比如(SELECT COUNT(*) FROM t) > 0是允许的，但(SELECT id FROM t LIMIT 1)会报错：子查询返回多于一行）
PostgreSQL 用 LOOP 和 EXIT WHEN 实现更安全的循环
PostgreSQL 没有 WHILE 语句，而是统一用 LOOP + EXIT WHEN 构建循环逻辑，语义更清晰，也更容易加退出条件。
DO $$
DECLARE
i INTEGER := 1;
BEGIN
LOOP
EXIT WHEN i > 10;
INSERT INTO log_table (msg) VALUES ('pg loop ' || i);
i := i + 1;
END LOOP;
END $$;-
EXIT WHEN在每次循环**末尾**检查，等价于 do-while；如需前置判断，可把EXIT WHEN放在循环体开头 - 变量赋值用
:=，不是=；=在 PL/pgSQL 中仅用于比较 - 如果循环中执行 DML，建议包裹在
SAVEPOINT内，避免单条失败导致整个匿名块失败
为什么多数情况下该避免在存储过程中写循环？
循环本身不是问题，问题是它常被用来替代集合操作——这是性能杀手。
- 逐行处理 10 万条记录，比一条
INSERT ... SELECT慢几十倍，尤其涉及索引更新、日志写入、锁竞争时 - SQL Server 的
WHILE在循环内做SELECT时，若未加OPTION (RECOMPILE)，可能复用低效执行计划 - MySQL 的存储过程循环无法并行，且每次迭代都走一遍解析器路径，开销远高于批量语句
- 真正需要循环的场景其实很少：比如调用外部 API（MySQL 不支持）、生成测试数据、迁移老结构、或处理无法用 JOIN 表达的递归依赖
如果非要用，优先考虑用 CTE + ROW_NUMBER() 或临时表模拟迭代，而不是硬写循环——特别是当循环次数超过几百次时，逻辑就该重新设计了。
