MySQL 8.0 推荐用 WITH RECURSIVE 处理树形结构，根本原因是它将多轮查询或应用层拼接压入单条 SQL，动态迭代适配无限层级，且每次 JOIN 均可利用 parent_id 索引实现高效等值查找，避免自连接因预设深度不足或索引失效导致漏查、全表扫描等问题。
MySQL 8.0 推荐用 WITH RECURSIVE 处理树形结构，根本原因是它把原来需要多轮查询或应用层拼接的逻辑，压进一条 SQL 里执行，且执行路径可控、语义清晰、索引可生效。
递归查询比自连接更可靠，尤其层级不确定时
自连接必须提前预估最大深度（比如写 4 层 JOIN），一旦实际数据超过预设层数，就查不全；而递归 CTE 是动态迭代，只要数据存在、递归未终止，就会继续往下找。常见错误现象包括：
- 写
LEFT JOIN category c2 ON c2.parent_id = c1.id后再LEFT JOIN category c3 ON c3.parent_id = c2.id，但第 5 级分类永远不出现 - 为避免漏查强行写到 10 层 JOIN，导致执行计划膨胀、
EXPLAIN显示type=ALL扫全表
递归方式天然适配“无限级”业务描述，无需硬编码层级数。
递归查询能真正利用 parent_id 索引
在 WITH RECURSIVE 中，每次迭代都是一次等值查找：INNER JOIN ... ON c.parent_id = t.id。只要 parent_id 有索引（推荐建 INDEX idx_parent_id (parent_id)），每轮都能走 ref 类型扫描。而自连接中，中间 JOIN 表（如 c2）常因关联字段缺失统计信息或别名混淆，导致优化器放弃使用索引，降级为全表扫描。
注意：锚点查询（起始条件）也必须命中索引，例如 WHERE id = 123 要求 id 是主键或有索引；若写成 WHERE name = '手机' 却没给 name 建索引，第一轮就慢，后续所有迭代都卡住。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
递归深度控制和终止逻辑必须显式管理
MySQL 不会自动感知树已到底层——它靠 JOIN 条件是否还能产出新行为判断是否继续。这意味着：
- 如果
parent_id允许为0表示根节点，向上递归时要加WHERE c.parent_id != 0，否则最后一轮会查出id = 0的脏数据 - 默认递归上限是
cte_max_recursion_depth = 1000，超深组织架构（如 2000 层代理关系）会直接报错ERROR 1105 (HY000): Recursive query aborted after 1000 iterations - 必须提前执行
SET SESSION cte_max_recursion_depth = 3000，且该设置仅对当前会话有效
另外，UNION ALL 是强制要求，用 UNION 会导致去重开销剧增，还可能因隐式类型转换（比如 parent_id 是 INT，但锚点里写了 '1' 字符串）让某轮结果被误判为重复而丢弃，造成断链。
向下查子树和向上查祖先，JOIN 方向不能反
这是最容易写错的地方。两者的区别不在语法结构，而在 JOIN 条件方向和起始点：
- 向下查（如查某分类下所有子分类）：锚点是父节点，递归部分是
ON c.parent_id = t.id（子的 parent_id 等于父的 id） - 向上查（如生成面包屑路径）：锚点是叶子节点，递归部分是
ON c.id = t.parent_id（父的 id 等于子的 parent_id）
如果方向写反，要么返回空，要么查出完全无关的分支。实际调试时，建议先单独跑锚点语句确认起始行存在，再看第一轮递归是否能连出一条有效记录——很多问题其实在第二行就暴露了。
