Python不支持递归CTE，WITH RECURSIVE是数据库原生功能；“Python递归查数据库”实为低效N+1查询，应将递归逻辑下推至数据库层，用一条WITH RECURSIVE完成树形结构展开，避免网络开销与连接池耗尽。
Python 本身不支持递归公用表表达式（CTE），WITH RECURSIVE 是 SQL 标准语法，由数据库引擎（如 PostgreSQL、SQL Server、SQLite 3.8.3+、MySQL 8.0+）原生执行。所谓“Python 递归查询数据库”，本质是 Python 程序反复发 SQL 请求——这不仅慢，还容易触发连接池耗尽、超时、锁竞争等问题。真正该优化的不是 Python 侧的循环调用，而是把递归逻辑下推到数据库层，用一条 WITH RECURSIVE 查询完成整棵树/层级结构的展开。
为什么不能在 Python 里“递归查数据库”
常见错误模式是：查出根节点 → 循环对每个子节点再发一次 SELECT * FROM t WHERE parent_id = ? → 再查子节点的子节点……这叫 N+1 查询，实际发出几十甚至上千条 SQL。
典型症状包括：
- 日志里看到成百条几乎一样的
SELECT ... WHERE parent_id = ?调用 - 数据库连接数飙升，
psycopg2.OperationalError: too many clients already - 响应时间随树深度/宽度非线性增长，查 5 层可能要 2 秒，查 7 层直接超时
根本原因：网络往返 + 连接开销 + 数据库解析每条 SQL 的成本，远高于单次复杂查询。
立即学习“Python免费学习笔记（深入）”；
PostgreSQL / SQLite 怎么写 WITH RECURSIVE 查树形结构
WITH RECURSIVE 查树形结构假设有一张组织架构表 org_unit：
CREATE TABLE org_unit (
id INTEGER PRIMARY KEY,
name TEXT,
parent_id INTEGER REFERENCES org_unit(id)
);
想查 ID=1 的部门及其所有下级（含子孙），SQL 应写成：
WITH RECURSIVE tree AS (
-- 锚点：起始节点
SELECT id, name, parent_id, 0 AS level
FROM org_unit
WHERE id = 1
<pre class="brush:php;toolbar:false;">UNION ALL
-- 递归部分：找子节点
SELECT c.id, c.name, c.parent_id, p.level + 1
FROM org_unit c
JOIN tree p ON c.parent_id = p.id) SELECT * FROM tree ORDER BY level;
关键点：
- 锚点（anchor）必须能快速命中（加索引！确保
parent_id和查询字段有索引） -
UNION ALL不去重，比UNION快；若数据本身无环，无需额外防重逻辑 - SQLite 默认关闭递归，首次需执行
PRAGMA recursive_triggers = ON（但注意：SQLite 的WITH RECURSIVE支持有限，深度默认上限 1000，可调PRAGMA max_recursive_depth = 3000）
Python 怎么安全调用这条 SQL（避免参数注入+超时）
别拼字符串，用参数化查询；别用 fetchall() 一把捞全（内存爆炸），尤其当结果可能上万行时：
import psycopg2
from contextlib import contextmanager
<p>@contextmanager
def get_db_conn():
conn = psycopg2.connect("dbname=test user=pg")
try:
yield conn
finally:
conn.close()</p><p>sql = """
WITH RECURSIVE tree AS (
SELECT id, name, parent_id, 0 AS level
FROM org_unit
WHERE id = %s
UNION ALL
SELECT c.id, c.name, c.parent_id, p.level + 1
FROM org_unit c
JOIN tree p ON c.parent_id = p.id
)
SELECT id, name, level FROM tree ORDER BY level;
"""</p><p>with get_db_conn() as conn:
with conn.cursor(name="tree_cursor") as cur: # 使用服务器端游标
cur.execute(sql, (root_id,))
for row in cur: # 流式读取，不加载全量到内存
process(row)
注意事项：
- PostgreSQL 用命名游标（
name=...）启用服务器端游标，避免客户端内存吃满 - SQLite 不支持服务器端游标，但可用
conn.execute(...).fetchmany(100)分批拉取 - 务必设查询超时：
conn.cursor().execute("SET statement_timeout = '5s'")（PostgreSQL）
如果数据库不支持 WITH RECURSIVE（如 MySQL 5.7 或旧版 Oracle）
WITH RECURSIVE（如 MySQL 5.7 或旧版 Oracle）没有优雅解法——只能接受妥协：
- 方案一：应用层缓存整棵树（如 Redis 存 JSON），定时或通过 binlog 更新，适合读多写少
- 方案二：改表结构，增加
path字段（如/1/5/12/）或lft/rgt（闭包表），用普通 B-tree 索引加速祖先/后代查询 - 方案三：升级数据库版本（MySQL 8.0+ 已支持
WITH RECURSIVE）
硬要在 Python 里模拟递归查，至少加两道保险：
- 限制最大递归深度（如
max_depth=6），防止意外形成长链导致雪崩 - 所有子查询走连接池 + 设置
timeout，单次失败不中断整体流程
真正省事又可靠的做法，永远是让数据库干它该干的事：把递归逻辑交给它，Python 只管收结果。
