根节点由业务逻辑决定，通常指parent_id为NULL或等于自身id的记录；需先验证数据特征再写SQL，查全部根节点最稳方式是直接WHERE条件过滤。

根节点怎么定义？先确认数据特征再写SQL

根节点不是靠猜出来的，而是由业务逻辑决定的：通常指 parent_id 为 NULL 或等于自身 id 的记录。不同表设计差异很大，比如有些系统用 0 表示根，有些用 ''（空字符串），甚至有把根节点硬编码为 1 的遗留库。

查之前务必先验证：

• SELECT COUNT(*) FROM tree_table WHERE parent_id IS NULL;
• SELECT DISTINCT parent_id FROM tree_table LIMIT 5;
• 检查 parent_id 字段类型是否和 id 一致（常见坑：一个是 INT，一个是 VARCHAR，导致后续 JOIN 失效）

递归CTE查根节点：只适合“从子找父”反推场景

递归CTE（WITH RECURSIVE）本质是自底向上遍历，它适合已知某个子节点，想一路找到它的根。但如果你只是想列出所有根节点，**递归CTE是杀鸡用牛刀，还容易出错**。

典型错误写法：

WITH RECURSIVE cte AS (
  SELECT id, parent_id FROM tree_table WHERE parent_id IS NULL  -- 这里就已是根了，还递归啥？
  UNION ALL
  SELECT t.id, t.parent_id FROM tree_table t INNER JOIN cte ON t.parent_id = cte.id
)
SELECT * FROM cte;

这段代码实际查的是整棵树，不是根节点集合。真要反向找根（比如给定 id = 123，查它的根），才该这么写：

• 锚点（anchor）选子节点：SELECT id, parent_id FROM tree_table WHERE id = 123
• 递归部分往 parent_id 走：JOIN ... ON cte.parent_id = t.id
• 终止条件隐含在 JOIN 失败时——当 parent_id 指向不存在的 id，递归就停了

查全部根节点：子查询或直接WHERE最稳

99% 的“查根节点”需求，其实只要一行：

SELECT * FROM tree_table WHERE parent_id IS NULL;

如果根节点用其他值标识，就换成对应条件：

• 根为 0：WHERE parent_id = 0
• 根为自身：WHERE id = parent_id
• 兼容多种情况（谨慎用）：WHERE COALESCE(parent_id, 0) = 0，但要注意 COALESCE 可能干扰索引使用

子查询只在需要关联其他表或过滤动态条件时才有意义，例如：“找出所有根节点中，下属节点总数超过10的那些”：

SELECT r.* FROM tree_table r
WHERE r.parent_id IS NULL
  AND (
    SELECT COUNT(*) FROM tree_table c
    WHERE c.parent_id = r.id OR c.id = r.id -- 包含自己
  ) > 10;

性能与可维护性：别让CTE掩盖设计问题

真正难的从来不是怎么写SQL，而是表结构本身是否支持高效查询。如果频繁需要查根、查深度、查路径，说明可能缺一个 root_id 冗余字段或物化路径（如 /1/5/23/）。

递归CTE 在 PostgreSQL / SQL Server / MySQL 8.0+ 中可用，但 SQLite 和旧版 MySQL 不支持；子查询则全平台通用。更隐蔽的坑是：递归深度默认可能被限制（如 PostgreSQL 的 max_recursion_depth），线上查着查着突然报错 ERROR: stack depth limit exceeded。

所以，动手前先问一句：这个“根节点”是静态不变的，还是随业务规则动态变化的？前者直接 WHERE，后者才值得考虑加字段或改模型。