必须先启用 ltree 扩展，否则视图中无法使用 path ~ 或 @>；需执行 CREATE EXTENSION IF NOT EXISTS ltree;，并确保基表建有 USING gist(path) 索引。
必须先启用 ltree 扩展，否则视图里用不了 path ~ 或 @>
PostgreSQL 视图本身不阻止使用 ltree 操作符，但前提是扩展已全局启用。很多人在创建视图时报错 operator does not exist: ltree ~ unknown，根本原因不是视图语法问题，而是漏了这步：
-
CREATE EXTENSION IF NOT EXISTS ltree;必须由超级用户或具有CREATE权限的角色执行 - 扩展只需在数据库内执行一次，不是每次建视图前都要运行
- 如果用的是只读用户连接，而扩展是别人建的，仍可正常使用——但该用户需对
ltree类型有USAGE权限（通常默认具备）
视图中用 path ~ 'pattern' 匹配子树时，注意点号要转义
正则风格的 ~ 运算符把点号 . 当作正则元字符，直接写 '1.2.*' 会匹配 '1x2y' 这类非法路径。正确做法是双反斜杠转义：
- 查以
1.2开头的所有后代：path ~ '^1\.2\..*' - 查直接子节点（下一级）：
path ~ '^1\.2\.\d+$'（假设你用纯数字标签） - 若标签含字母或下划线，改用
[a-zA-Z0-9_]+替代\d+，例如：path ~ '^1\.2\.[a-zA-Z0-9_]+$' - 避免写
path LIKE '1.2%'——它不走ltree索引，性能差一个数量级
视图里想高效查祖先，优先用 @> 而非 ~
@> 是 ltree 的专属包含运算符，语义清晰且能命中 GiST 索引；~ 虽灵活但容易写成全表扫描。比如查某节点的所有祖先：
- ✅ 推荐：
SELECT * FROM tree_view WHERE '1.2.3.4' @> path;—— 走索引，快 - ❌ 避免：
SELECT * FROM tree_view WHERE path ~ '^(1|1\.2|1\.2\.3)\.?$';—— 手动枚举，不可维护，不走索引 - 注意：
@>左操作数是后代路径，右操作数是候选祖先路径，顺序不能反 - 如果视图封装了多层 JOIN，确保
@>出现在 WHERE 最外层，别被嵌套子查询裹住导致索引失效
视图定义里加 USING gist(path) 索引没用，得单独建
视图是查询的封装，不存储数据，也不支持在 CREATE VIEW 语句里声明索引。所谓“优化视图性能”，本质是优化其底层表的索引和查询写法：
- 索引必须建在基表上：
CREATE INDEX CONCURRENTLY idx_tree_path_gist ON tree_table USING gist (path); - GiST 比 SP-GiST 更通用，适合混合查询（
@>,~,）；SP-GiST 在纯前缀查询（如path ）时略快，但兼容性稍弱 - 如果视图常按深度过滤，可加函数索引：
CREATE INDEX idx_tree_depth ON tree_table ((ldepth(path))); - 别忘了
VACUUM ANALYZE tree_table;—— 统计信息不准时，即使有索引，查询计划也可能选错
真正容易被忽略的点：ltree 标签里不能出现空格、连字符、中文（除非你启用了 ICU collation 并显式配置），一旦插入非法字符，整行写入失败，而视图查询时不会报错，只会静默漏掉数据。
