SQL 循环语句 WHILE、LOOP 使用方法

sql标准不支持while/loop，仅少数数据库在存储过程中提供；应优先用递归cte、join、窗口函数等集合操作替代，避免性能下降和维护难题。

SQL 里没有标准的 WHILE 或 LOOP 语句

绝大多数 SQL 方言（如 postgresql、sqlite、mysql 8.0 之前）根本不支持过程式循环语法。你写的 WHILE 或 LOOP 很可能直接报错：Error: syntax error at or near "WHILE"。这不是你写错了，是 SQL 标准本身不提供这类控制流——它本质是声明式语言，不是编程语言。

真正能用上 WHILE 的场景，只存在于少数支持存储过程的数据库引擎中，且必须在特定上下文里：

• MySQL：仅在 STORED PROCEDURE 或 function 内部可用，不能在普通查询中直接写
• SQL Server：仅在 batch 或 stored procedure 中生效，WHILE 是 T-SQL 扩展
• PostgreSQL：要用 plpgsql 语言定义函数，写 LOOP 或 WHILE，但不能在 select 里嵌入

MySQL 存储过程中 WHILE 的正确写法和常见崩溃点

想在 MySQL 里用 WHILE，必须先创建一个存储过程，再在里面写逻辑。漏掉 BEGIN...END 块、忘记声明变量、或把 WHILE 放在过程体外，都会导致语法错误。

典型错误现象：ERROR 1064 (42000): You have an error in your SQL syntax，往往卡在 WHILE 开头或 DO 关键字附近。

• 变量必须用 DECLARE 显式声明，且只能在 BEGIN...END 内部
• WHILE 后面不能跟分号，条件后直接接 DO
• 循环体必须用 END WHILE 结束，不是 END 或 END LOOP
• 别在循环里反复执行 SELECT 而不加 INTO —— 会报 Subquery returns more than 1 row

简短示例（计算 1 到 5 的和）：

DELIMITER $$ CREATE PROCEDURE calc_sum() BEGIN   DECLARE i INT DEFAULT 1;   DECLARE total INT DEFAULT 0;   WHILE i <= 5 DO     SET total = total + i;     SET i = i + 1;   END WHILE;   SELECT total; END$$ DELIMITER ; CALL calc_sum();

替代方案：用递归 CTE 模拟循环（PostgreSQL / SQL Server / MySQL 8.0+）

如果你只是想生成序列、遍历层级、或做有限次迭代，递归 WITH RECURSIVE 更安全、更可预测，也更容易调试。它不依赖存储过程，能直接跑在普通查询中。

性能影响明显：递归深度受 max_recursive_iterations（MySQL）或 max_stack_depth（PostgreSQL）限制，超限会报错 Recursive query aborted after 1001 iterations。

• 必须包含 anchor member（初始行）和 recursive member（引用自身）
• PostgreSQL 要求递归引用必须在 union ALL 右侧，MySQL 要求 WITH 后紧跟 RECURSIVE
• 避免无终止条件，比如 level = level + 1 却没写 WHERE level

生成 1–5 数字的等价写法：

WITH RECURSIVE nums(n) AS (   SELECT 1   UNION ALL   SELECT n + 1 FROM nums WHERE n < 5 ) SELECT n FROM nums;

为什么不该执着于 SQL 循环

即使语法跑通，用 WHILE 处理千行数据，大概率比单条集合操作慢 10–100 倍。数据库优化器对集合操作极其擅长，对逐行逻辑几乎不优化。

真实项目里，95% 的“需要循环”场景，其实可以用以下方式更干净地解决：

• 用 JOIN 替代循环查表
• 用窗口函数（ROW_NUMBER()、SUM() OVER()）替代累加逻辑
• 用 INSERT ... SELECT 代替循环插入
• 把复杂流程提到应用层（Python/Java），让 SQL 只负责读写原子数据

最容易被忽略的一点：存储过程里的 WHILE 无法被 ORM（如 django ORM、SQLAlchemy）直接调用，也不方便单元测试——一旦业务逻辑锁死在数据库里，后续迁移和协作成本会突然变高。