PostgreSQL不支持SEARCH BREADTH语法，仅能通过depth列+ORDER BY实现视觉广度优先效果；递归执行虽内部广度优先，但结果顺序必须依赖最终ORDER BY保证，不可假设中间行序。
CTE递归查询中SEARCH BREADTH不被PostgreSQL支持
PostgreSQL根本不识别SEARCH BREADTH这个语法——它会直接报错syntax error at or near "BREADTH"。这是最常踩的坑：误以为PostgreSQL像Oracle或SQL Server那样原生支持SEARCH子句。实际从9.1到16.x所有版本，PostgreSQL只支持用ORDER BY对递归结果做**事后排序**，而非控制遍历顺序本身。
用depth列模拟广度优先排序
虽然不能控制执行时的遍历顺序，但你可以通过计算层级深度，在最终结果里实现视觉上“一层层展开”的效果：
-
depth必须作为递归CTE的输出列之一，初始值为0，每次递归+1 -
ORDER BY depth是必需的，否则结果顺序完全不可控 - 若同一层内需要稳定排序（比如按
id升序），应追加次要排序：ORDER BY depth, id - 注意：
depth列本身不加速查询，只是排序依据；索引对它无效
WITH RECURSIVE search_tree(id, link, data, depth) AS ( SELECT t.id, t.link, t.data, 0 FROM tree t WHERE t.id = 1 -- 起始节点 UNION ALL SELECT t.id, t.link, t.data, st.depth + 1 FROM tree t INNER JOIN search_tree st ON t.id = st.link ) SELECT * FROM search_tree ORDER BY depth, id;
为什么不能靠ORDER BY depth保证真正广度优先？
因为PostgreSQL递归CTE的执行引擎内部确实是广度优先生成行（这点文档明确说了），但这个行为不保证对外可见——尤其当存在并发修改、并行查询或优化器重排时，ORDER BY前的中间结果顺序可能被打乱。你唯一能依赖的，只有最终ORDER BY强制施加的顺序。
- 不要在应用层假设“第1–5行一定是depth=0”，必须显式
ORDER BY - 如果业务强依赖层级边界（比如分页取某一层），得用
WHERE depth = N单独过滤，而不是靠偏移 -
depth列会增加每行存储开销，对超大结果集（百万级）要考虑内存和网络传输成本
比depth更可靠的层级控制手段
当树很深或分支极宽时，单纯depth排序可能不够用。这时要结合业务逻辑加约束：
- 用
LIMIT限制总返回行数，防止OOM：SELECT * FROM search_tree ORDER BY depth, id LIMIT 1000 - 对起始节点加精确条件，避免全表扫描递归源：
WHERE t.parent_id IS NULL比WHERE t.id IN (1,2,3)更易走索引 - 如果只关心某几层，把
depth下推到递归部分：WHERE st.depth ，提前截断递归，性能提升明显
真正容易被忽略的是：递归深度本身受max_recursive_depth参数限制（默认100），超限会报错reached maximum recursion depth——而这个错误不会出现在EXPLAIN里，只有运行时才暴露。
