应优先使用 #>> 提取 jsonb 字符串值以避免类型转换开销，对高频字段建议创建生成列并建 b-tree 索引，同时注意 null 行为差异。
使用 #> 提取 JSONB 路径时，PostgreSQL 会返回一个 jsonb 类型值，而非原始数据类型（如 text、integer）。若后续需做比较、排序或函数计算，直接强转（如 ::text）可能触发隐式转换开销，且在 WHERE 或 ORDER BY 中频繁调用会显著拖慢查询性能。
避免重复路径解析与多次类型转换
#> 每次调用都会重新解析整个 JSONB 文档并定位路径，即使同一路径被多次引用。若 SQL 中多处用到同一个子字段（例如 data #> '{user,profile,name}'），应提取为 CTE 或子查询列，再统一转换。
- ❌ 低效写法：多次调用 + 多次转换
SELECT id, (data #> '{user,profile,name}')::text AS name
FROM logs
WHERE (data #> '{user,profile,age}')::int > 25
ORDER BY (data #> '{user,profile,name}')::text;
- ✅ 推荐写法：一次提取 + 列别名复用
SELECT id, name
FROM (
SELECT id,
(data #> '{user,profile,name}')::text AS name,
(data #> '{user,profile,age}')::int AS age
FROM logs
) t
WHERE age > 25
ORDER BY name;
优先用 #>> 替代 #> + ::text
当目标是提取字符串值时，#>> 直接返回 text（自动去除引号、处理转义），比 #> 后加 ::text 少一次类型转换，执行计划中通常显示更低的 cost。
-
data #> '{name}'→ 返回"John"（jsonb） -
data #>> '{name}'→ 返回John（text） - 对索引友好：若已建
jsonb_path_ops表达式索引，如ON logs ((data #>> '{name}'))，可加速 text 级匹配
对高频查询字段考虑生成列 + 索引
若某 JSONB 字段（如 data #>> '{status}'）被大量用于 WHERE / JOIN / GROUP BY，建议创建存储型生成列并建普通 B-tree 索引：
- 添加生成列：
ALTER TABLE logs ADD COLUMN status TEXT GENERATED ALWAYS AS (data #>> '{status}') STORED; - 创建索引：
CREATE INDEX idx_logs_status ON logs (status); - 查询时直接引用
status列，完全绕过 JSONB 解析，性能接近原生字段
注意 NULL 和缺失路径的隐式行为
#> 与 #>> 在路径不存在时均返回 NULL，但类型不同：#> 返回 jsonb NULL，#>> 返回 SQL NULL（unknown 类型）。在 COALESCE 或 CASE 中混合使用可能引发隐式转换警告；显式指定类型更安全：
- 稳妥写法：
COALESCE(data #>> '{score}', '0')::int - 避免：
COALESCE(data #> '{score}', '0')::text（类型不兼容报错）
