MySQL树形查询：id与pid关联实现

处理基于id和pid的树形结构查询，是不少开发者的日常。根据MySQL版本和业务场景的不同，方法也有差异。下面梳理几套常用方案，供参考。

1. 使用递归公用表表达式（推荐 MySQL 8.0+）

这是官方推荐的标准做法，性能不错，语法也干净——利用WITH RECURSIVE实现递归查询。先看向下查询：找某个节点的所有子级。

WITH RECURSIVE tree_cte AS (
    -- 锚点成员：指定起始节点
    SELECT id, pid, name, 1 as level
    FROM tree
    WHERE id = 1  -- 替换为指定的父节点ID
    UNION ALL
    -- 递归成员：查找子节点
    SELECT t.id, t.pid, t.name, tc.level + 1
    FROM tree t
    INNER JOIN tree_cte tc ON t.pid = tc.id
)
SELECT * FROM tree_cte;

向上查询也是一样，只不过方向反过来：从子节点开始，不断找父节点。

WITH RECURSIVE parent_cte AS (
    -- 锚点成员：指定起始节点
    SELECT id, pid, name
    FROM tree
    WHERE id = 5  -- 替换为指定的子节点ID
    UNION ALL
    -- 递归成员：查找父节点
    SELECT t.id, t.pid, t.name
    FROM tree t
    INNER JOIN parent_cte pc ON t.id = pc.pid
)
SELECT * FROM parent_cte;

2. 使用自定义函数（适用于 MySQL 5.7及以下）

如果你的MySQL版本还停留在5.7或更早，没关系，可以用自定义函数曲线救国。核心思路是用循环配合FIND_IN_SET或GROUP_CONCAT，把子节点ID拼成一个字符串，再过滤出来。

具体逻辑大致是这样的：初始化一个字符串，存根节点ID；然后循环查当前层级所有节点的子节点ID，拼接到字符串里；直到找不到新子节点为止。最后返回拼接后的ID列表，外层用FIND_IN_SET(id, get_child_ids(root_id))来过滤。

不过得留个心眼：数据量大了之后性能会打折扣，而且受group_concat_max_len参数限制，需要提前调大这个值。

3. 应用层组装（通用方案）

如果不想给数据库太大压力，或者业务逻辑本身就复杂，可以考虑另一种思路：一次性把数据捞出来，在应用内存里组装成树。

3.1 SQL查询：一次性查出所有相关节点（或者干脆全表），按pid和id排序。

SELECT * FROM tree ORDER BY pid, id;

3.2 代码处理：在Java、Python、Go等后端语言中，遍历列表，用一个Map把节点挂到对应的父节点下。具体做法是：先建一个Map，第一遍遍历把所有节点放进去；第二遍遍历，根据每个节点的pid从Map中找到父节点，把当前节点追加到父节点的children列表里。最后，那些pid为0或null的节点就是根节点，可以作为树的入口。

4. 其他高级设计模式（针对高性能需求）

如果对读取性能有极致的追求，而且写操作不太频繁，那么改变表结构可能是更根本的解法。常见的高级设计包括：

• 路径枚举（Path Enumeration）：加一个path字段（比如0,1,5,10），查询子节点时用LIKE '0,1,%'。简单直接，但路径更新时有点麻烦。
• 闭包表（Closure Table）：专门建一张关系表，存储所有祖先–后代的关系对。查询时直接做Join，效率非常高，但维护成本会高一些（增删节点时需要同步维护关系表）。
• 嵌套集（MPTT）：加lft和rgt字段，通过范围查询一下子拿到整个子树。读取性能极佳，但插入和移动节点时需要大规模更新左右值，适合写少读多的场景。

总结建议

总结来说，如果你的MySQL版本在8.0以上，无脑选方案1（WITH RECURSIVE），干净利落，数据库引擎还会帮你优化。要是还跑在5.7上且数据量不大，自定义函数也能凑合用。数据量大或业务逻辑复杂，推荐方案3（应用层组装），把递归压力从数据库转移到应用服务器，伸缩性更好。至于极致读性能的场合，闭包表或路径枚举值得考虑，前提是你愿意承担额外的维护成本。