锚定查询和递归JOIN的关联字段必须走索引，否则每轮全表扫描导致性能雪崩；需为WHERE条件字段及ON子句中“被驱动表”的关联字段（如manager_id）建立合适索引，并合理设置cte_max_recursion_depth与MAX_EXECUTION_TIME。
锚定查询必须走索引，否则递归从第一轮就卡住
递归 CTE 的执行是分轮次的：先跑锚定部分（WHERE 条件），拿到初始行集；再用这些行去驱动递归部分的 JOIN。如果锚定查询没走索引，哪怕只查一个节点，也可能全表扫描——后续每一轮递归都会基于这个低效结果反复 JOIN，性能雪崩。
常见错误是写 WHERE name = '技术部' 却没在 name 字段建索引；或者用 WHERE id IN (1001, 1002) 但 id 是主键没问题，可一旦换成 WHERE code = 'DEV-001' 就忘了加索引。
- 锚定条件字段必须有单列索引或作为联合索引最左前缀
- 避免在锚定部分用函数或表达式，比如
WHERE UPPER(name) = 'TECH'会失效 - 若起点不固定（如按名称查），优先给名称字段加索引；若总是按 ID 查，确保 ID 是主键或有索引
递归 JOIN 的 ON 条件必须命中索引，且方向要对
递归成员里典型的写法是 JOIN employees e ON e.manager_id = s.id。这里数据库要用 s.id 去查 e.manager_id，所以真正需要索引的是 manager_id 字段，不是 id。
很多人建了 INDEX idx_id (id) 觉得够了，其实完全没用——id 是被拿来当“查找值”，而 manager_id 才是被扫描的列。执行计划里如果看到 Type: ALL 或 Extra: Using where，基本就是这儿没索引。
- 必须在递归 JOIN 的“被驱动表”的关联字段上建索引，即
ON 子表.字段 = 主表.字段中的子表.字段 - 如果关联字段允许 NULL（如
manager_id可为 NULL），索引仍有效，但注意NULL值不会参与 JOIN 匹配 - 联合索引如
INDEX idx_mgr_status (manager_id, status)在递归中也能用，前提是status过滤条件写在递归成员的WHERE里且顺序匹配
深度过大时，MAX_EXECUTION_TIME 和 cte_max_recursion_depth 得手动设
MySQL 默认递归上限是 1000 层（cte_max_recursion_depth），超了直接报错 ERROR 3636 (HY000): Recursive query aborted after 1000 iterations。但更隐蔽的问题是：即使没超深度，深层递归也可能因耗时过长被 MAX_EXECUTION_TIME 中断，返回空结果而不报错。
这不是语法问题，是资源限制。比如查一个 8 层深、每层平均 200 节点的组织树，第 7 轮可能生成 12800 行中间结果，JOIN 开销指数上升，5 秒内根本跑不完。
- 执行前先设
SET SESSION cte_max_recursion_depth = 2000;，根据业务最大可能深度留余量 - 配合
SET SESSION MAX_EXECUTION_TIME = 10000;（单位毫秒），防止超时静默失败 - 这两个变量只对当前 session 有效，应用层需在执行 CTE 前显式设置
别忽略 EXPLAIN ANALYZE 里 “Recursive” 行的 rows 和 filtered
EXPLAIN ANALYZE 输出中，递归部分会标出 Recursive 类型的行。关键要看它的 rows（本轮实际输出行数）和 filtered（过滤后保留比例）。如果某轮 rows 突增十倍、filtered 低于 10%，说明 JOIN 条件太宽或缺少过滤，正在把大量无效节点拖进下一轮。
例如锚定查出 1 个部门，第一轮递归返回 50 个子部门，第二轮却返回 2000 行——大概率是 employees 表里 manager_id 没索引，导致每次 JOIN 都全表扫一遍，再靠 WHERE 硬过滤。
- 重点关注每轮递归的
rows是否随深度线性增长（合理），还是指数膨胀（危险） -
filtered长期低于 30% 说明 WHERE 条件没走索引，或条件本身选择性差 - 如果发现某轮
Extra里有Using temporary; Using filesort，说明中间结果集太大，已触发磁盘临时表
递归 CTE 的性能瓶颈从来不在语法本身，而在每一轮执行是否能精准命中索引。最容易被跳过的其实是递归 JOIN 的索引方向——你得时刻记住：数据库是拿上一轮结果去查下一张表，不是反过来。
