PostgreSQL中能否用LTREE路径替代ID列并设为主键？

1. 是否可以完全移除ID列？ #

可以，但前提是能保证PATH列的最后一个标签始终全局唯一——因为原ID作为主键的核心作用是唯一标识行，现在要靠PATH的最后一段替代这个唯一性。如果你的业务逻辑能严格确保每次生成PATH时，最后一个标签（原ID）不会重复，那移除ID列是可行的。

比如你的PATH格式是root.parent.abc123，其中abc123是原ID，只要所有行的PATH最后一个标签没有重复，就可以通过PATH定位目标行，无需单独的ID列。

2. 能否将PATH LTREE设为主键？ #

可以，但必须满足两个核心条件：

• PATH列全局唯一：主键的核心要求是唯一性，只要你的PATH生成逻辑能保证每行的PATH不重复（结合你的场景，只要原ID唯一且PATH的前缀不会导致整体重复即可），就符合主键的唯一性要求。
• PATH列非空：主键列默认强制非空，LTREE类型本身支持非空约束，只要插入数据时确保PATH不会为NULL即可。

另外PostgreSQL完全支持将LTREE类型设为主键，底层会为其创建唯一索引，查询性能也能得到保障——只是LTREE的索引基于树结构，和普通文本主键的索引特性略有差异，只要你的查询逻辑适配，不会有明显性能问题。

3. 这种做法存在哪些风险？ #

• 唯一性失控风险：如果后续业务逻辑变更，PATH生成规则被修改，导致不同行的PATH最后一个标签重复，或者整个PATH重复，会直接触发主键冲突。比如误生成两个root.node.x123的PATH，插入会失败，且排查难度比单独的ID列更高。
• 查询复杂度提升：原来用ID查询是直接匹配单一值，现在要定位某一行，要么用完整PATH匹配，要么用LTREE操作符（比如PATH @> '*.x123'::ltree匹配最后一个标签为x123的行），后者依赖LTREE索引，写法比直接用ID更复杂。如果是频繁基于原ID查询的场景，性能可能略低于文本ID主键。
• 数据修改成本高：如果需要修改原ID对应的标签（比如业务要求更新节点标识），必须修改整个PATH列；而PATH作为主键，修改时会触发关联表的外键更新（若存在关联），成本远高于修改单独的ID列。
• 兼容性问题：部分ORM框架或工具对LTREE类型的支持不如普通文本类型友好，可能需要额外配置或自定义类型转换器，增加开发和维护成本。

内容的提问来源于stack exchange，提问作者sudoExclamationExclamation