SQL 中没有标准循环语句，WHILE、FOR 仅限于特定方言的存储过程内使用；普通查询应使用递归 CTE、窗口函数或应用层处理。
SQL 里根本没有标准循环语句
绝大多数 SQL 方言（如 PostgreSQL、MySQL、SQLite、SQL Server 标准模式）不支持 FOR、WHILE 这类过程式循环语法——你写的 WHILE 报错，不是写错了，是根本不存在。只有少数环境（如 SQL Server 的 T-SQL、Oracle 的 PL/SQL、PostgreSQL 的 plpgsql）在存储过程或函数体内才允许过程控制结构，且必须包裹在 BEGIN ... END 块中，不能直接在普通查询里用。
常见错误现象：ERROR: syntax error at or near "WHILE" 或 Unknown command 'FOR'；本质是把应用层逻辑误当成了 SQL 能力。
- 普通
SELECT/INSERT/UPDATE语句永远是集合操作，一次处理多行，不是一行一行“循环” - 真需要迭代逻辑，优先考虑：窗口函数、递归 CTE、生成序列（
generate_series）、或把循环提到应用代码里 - T-SQL 中的
WHILE只能在存储过程中用，且每次循环都可能触发隐式事务开销，性能极差
递归 CTE 替代简单计数循环（比如生成日期序列）
想“循环 30 次生成近一个月每天的日期”？别写 WHILE，用递归 CTE 更安全、可读、易优化。它本质是声明式生成，数据库能提前规划执行计划。
使用场景：填充缺失日期、树形结构遍历、步进计算（如累计求和）、模拟简单迭代逻辑。
- PostgreSQL / SQL Server / SQLite（3.35+）/ Oracle 都支持标准递归 CTE，语法统一为
WITH RECURSIVE - 必须定义终止条件（
WHERE level ），否则会无限递归并报错 <code>maximum recursion depth exceeded - 避免在递归支中做 JOIN 或子查询，会导致指数级膨胀；只对上一层结果做轻量计算
WITH RECURSIVE dates AS ( SELECT CURRENT_DATE::date AS d, 1 AS level UNION ALL SELECT d - INTERVAL '1 day', level + 1 FROM dates WHERE level < 30 ) SELECT d FROM dates;
UPDATE 多行时误用子查询模拟“循环”，导致性能雪崩
常见错误：用 (SELECT ... FROM t2 WHERE t2.id = t1.id) 在 UPDATE 中逐行查关联值，看起来像“为每行循环一次”，实际是 N+1 查询，数据量一过万就卡死。
真正高效的做法是把关联逻辑一次性做完，用 JOIN 或 FROM 子句（PostgreSQL）/ MERGE（SQL Server）/ 相关更新语法。
- MySQL 不支持
UPDATE ... JOIN以外的多表更新语法，写UPDATE t1 SET x = (SELECT y FROM t2 WHERE t2.id = t1.id)会强制对 t1 每行都跑一遍子查询 - PostgreSQL 支持
UPDATE t1 SET x = t2.y FROM t2 WHERE t2.id = t1.id，这是单次哈希连接，速度差一个数量级 - 如果子查询含聚合或非确定性函数（如
RANDOM()），还可能产生不可预期结果
存储过程中用 WHILE 的三个硬约束
仅当你明确在 SQL Server 存储过程或 PostgreSQL 函数中使用 WHILE 时，必须守住这三条线，否则调试成本远高于收益。
- 每次循环体必须包含明确的
SET @i = @i + 1或类似递增/退出逻辑，漏写等于死循环（SQL Server 可能超时中断，PG 则夯住连接） - 循环内避免执行 DML（尤其是
INSERT单行），改用批量操作：先拼临时表，再一次性INSERT INTO ... SELECT - SQL Server 的
WHILE默认每个循环都是独立事务上下文，若没显式BEGIN TRAN，出错后无法回滚整个块；PG 的 plpgsql 中则需手动EXCEPTION捕获
复杂点从来不在语法能不能写，而在于：你是否清楚每一行 SQL 是在客户端执行、服务端解析、还是被下推到存储引擎层——循环类需求，90% 的时候该砍掉，换成集合思维。
