SQL 循环语句优化与性能调优

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% 的时候该砍掉，换成集合思维。