MySQL 8.0+ 用 WITH RECURSIVE 实现无限级分类需正确编写锚点（如 WHERE id = 1）和递归部分（JOIN 条件为 c.parent_id = ct.id），注意 UNION ALL、递归深度限制及字段类型一致；PostgreSQL 唯一替代 CONNECT BY 的方案是 WITH RECURSIVE，并支持 SEARCH 控制遍历顺序；左右值（MPTT）模型依赖手动维护 lft/rgt 区间，适合读多写少场景。
MySQL 8.0+ 怎么用 WITH RECURSIVE 查无限级分类
直接能用，但必须写对锚点和递归两部分，漏掉 UNION ALL 或搞反连接方向，结果就为空或死循环。
典型场景：查某个栏目下所有子栏目（含孙子、曾孙……），且表结构是普通父子关系（id/parent_id）。
-
WITH RECURSIVE的第一行（锚点）只能选顶层或指定起点，不能带WHERE过滤递归过程中的行 - 递归部分的
JOIN必须用上一层的id匹配下一层的parent_id，反着写会查不出子节点 - MySQL 默认递归深度限制为 1000，超深树要先设
SET SESSION cte_max_recursion_depth = 2000;
WITH RECURSIVE category_tree AS ( SELECT id, name, parent_id, 0 AS level FROM categories WHERE id = 1 -- 锚点：从根栏目开始 UNION ALL SELECT c.id, c.name, c.parent_id, ct.level + 1 FROM categories c INNER JOIN category_tree ct ON c.parent_id = ct.id -- 注意这里是 c.parent_id = ct.id ) SELECT * FROM category_tree ORDER BY level;
PostgreSQL 里 CONNECT BY 不可用，该用哪个替代
PostgreSQL 没有 CONNECT BY，唯一可靠方案就是 WITH RECURSIVE —— 它比 Oracle 的语法更严格，但语义一致。
常见错误是把递归查询当普通子查询用，比如在外部再套一层 ORDER BY 却没加 ORDER SIBLINGS BY 效果，导致层级顺序混乱。
- PostgreSQL 支持
SEARCH DEPTH FIRST BY name SET ordercol来控制遍历顺序（深度优先 / 广度优先） - 如果需要路径字符串（如
/1/5/23），得在递归中拼接：ct.path || '/' || c.id，初始锚点要设'/' || id - 递归字段类型必须完全一致，比如锚点用
TEXT拼路径，后续所有分支也得是TEXT，否则报错recursive reference must be of same type
左右值（MPTT）模型在 MySQL 中怎么建表和更新
左右值不是 SQL 标准，是人为维护的一套整数区间规则，查得快，但写操作极易出错——新增、移动节点时，不批量更新相邻记录的 lft/rgt 值，树就断了。
适用场景：读远多于写，且需频繁获取某节点全部祖先或子孙（不用递归、不依赖版本）。
- 表必须有
lft和rgt两个INT字段，并加索引：KEY idx_lft_rgt (lft, rgt) - 插入子节点前，得先给目标父节点右侧所有节点的
lft/rgt集体 +2；移动节点更复杂，涉及四段区间重算 - 查某节点所有后代：
SELECT * FROM categories WHERE lft > ? AND rgt （? 是该节点的左右值） - 没有数据库自动校验左右值合法性，上线前务必用脚本检查是否存在重叠、空洞、负数
递归 CTE 和左右值模型性能差多少
取决于数据量和查询模式。小树（
容易被忽略的是：递归 CTE 在 PostgreSQL 中支持并行计划，MySQL 8.0 目前不支持；而左右值一旦写错，修复成本远高于加个索引。
- 单纯查路径（从叶子到根）：递归 CTE 更自然，左右值得反向查
lft ?再排序 - 频繁移动节点：左右值需要大范围
UPDATE，可能锁表数秒；递归 CTE 完全无感，只改parent_id - ORM 如 Django 或 Laravel 自带 MPTT 支持，但默认不启用，得手动触发
rebuild()，这个动作本身就有风险
真要选，先看写操作频次——高就别碰左右值；再看 DB 版本，MySQL
