物化路径是一种数据建模策略，将树形结构中根到当前节点的完整路径以字符串形式（如'1/2/4'）直接存储于字段中，通过前缀匹配等高效查询替代递归计算，以写时开销换取读时高性能。
物化路径是什么
物化路径（Materialized Path）不是 SQL 视图，而是一种**数据建模策略**：把树形结构中从根到当前节点的完整路径，以字符串形式（如 '1/2/4' 或 'A.B.C'）直接存进字段里。它不依赖 WITH RECURSIVE 运行时计算，而是把“路径”当成普通列来查。
为什么能绕过递归查询的性能瓶颈
递归查询每次执行都要从根开始逐层 JOIN，深度越大、数据越多，性能越差；而物化路径把层级关系“固化”在单个字段中，查询变成简单的字符串匹配或前缀查询：
-
WHERE path LIKE '1/2/%'→ 查所有 2 的子节点 -
WHERE path = '1/2/4'→ 精确查节点 4 -
SELECT SUBSTRING_INDEX(path, '/', -1) AS leaf_id→ 快速提取当前节点 ID
只要对 path 字段建了 B-tree 索引，这些操作都是 O(log n)，不用触发递归引擎、不占临时内存、无深度限制风险。
和递归查询相比，物化路径的代价在哪
它用写时开销换读时性能，主要坑点集中在维护侧：
- 插入/移动节点时必须手动更新所有子孙的
path值（比如把'1/2'下的节点挪到'1/3'，整个子树路径都要重写） -
path字段长度需预估足够（例如用VARCHAR(255)存 10 层 ID，每层最多 10 位数字，就至少要 10×10+9=109 字符） - 无法直接表达“兄弟顺序”，除非额外加排序字段；也不支持跨树合并等动态关系
- MySQL 8.0+、PostgreSQL 都支持，但 Oracle 的
sys_connect_by_path是运行时函数，不算物化路径
什么时候该选物化路径而不是 WITH RECURSIVE
当你的树结构变更极少、查询极频繁、且层级深度不可控（比如分类目录、地区编码、权限菜单），物化路径就是更稳的选择。典型场景包括：
- 电商类目表，每天只同步一次，但每秒被搜索数百次
- 行政区划代码（如
'610000/610100/610102'），几乎只读 - 需要快速判断“是否为某节点后代”的权限校验
真正难的是权衡：你得接受写逻辑变重，换来的是彻底甩掉递归栈溢出、索引失效、执行计划飘忽这些 runtime 问题。
