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）直接调用，也不方便单元测试——一旦业务逻辑锁死在数据库里，后续迁移和协作成本会突然变高。
