GIN索引适合jsonb @>查询，速度快但空间占用大；GiST适合@@全文搜索但可能漏判；固定路径等值查询应选B-tree索引；实际选型取决于查询模式而非jsonb类型本身。
GIN 索引对 jsonb @> 查询快，但占空间大
当你要查某个 jsonb 字段是否包含特定键值对（比如 data @> '{"status": "active"}'），GIN 是首选。它把每个键值对展开成独立索引项，查找时能直接定位，响应通常在毫秒级。
但代价明显：一个中等复杂度的 jsonb 对象可能生成几十个索引项，索引体积轻松超过原表数据 2–3 倍。如果表写入频繁、JSON 结构又深又杂，VACUUM 压力和磁盘占用会很快成为瓶颈。
-
GIN默认用jsonb_ops，只支持@>、?、?&、?|这类“存在性”操作，不支持路径查询如data #> '{user, name}' - 想支持路径表达式，得显式指定
jsonb_path_ops，但它只加速@>和@@（全文匹配），且不支持?类操作——换用前务必验证查询是否覆盖 - 建索引时加
CONCURRENTLY避免锁表，但耗时更长；线上大表别省这一步
GiST 索引适合 jsonb @@ 全文搜索，但结果可能漏判
如果你用 to_tsvector + @@ 做 JSON 内容的全文检索（比如搜 data @@ to_tsquery('english', 'error & timeout')），GiST 比 GIN 更合适——尤其当 JSON 文本字段长、词汇多、更新频繁时。
原因在于 GiST 的树结构天然支持模糊边界和部分匹配，插入/更新开销比 GIN 小，且对 tsvector 的压缩更友好。但要注意：它的匹配是“损失型”的，可能把本该命中的文档漏掉（false negative），只是不会误命中（false positive）。
- 必须配合
to_tsvector('english', data->>'message')这类显式路径提取，不能直接对整个jsonb建GiST全文索引 -
GiST不支持@>操作；混用两种索引时，PostgreSQL 不会自动选最优，得靠EXPLAIN看执行计划 - 如果 JSON 中文本字段含大量停用词或特殊符号，
to_tsvector的配置要同步调优，否则索引有效性断崖下跌
查 jsonb ->> 'field' = 'value' 别用 GIN 或 GiST，用普通 B-tree
很多人一看到 jsonb 就默认上 GIN/GiST，但如果你只是按固定路径取字符串再等值比较（比如 data ->> 'email' = 'a@b.com'），最稳最快的是 B-tree 索引。
它体积小、维护成本低、范围查询也支持，而且 PostgreSQL 12+ 能直接在表达式上建索引：CREATE INDEX idx_email ON tbl ((data ->> 'email'));。这种写法比任何 GIN/GiST 都轻量，也更容易被查询规划器识别。
- 确保
->>右侧是常量字符串，不是变量或函数调用，否则索引可能失效 - 如果字段可能为
NULL，B-tree 默认不索引空值；需要查IS NULL，得加INCLUDE或单独建部分索引 - 多个固定路径查询（如 email + status），优先考虑组合 B-tree 索引，而不是堆叠多个 GIN
实际选型得看查询模式，不是 JSON 类型本身
有没有 jsonb 不决定用哪个索引，真正起作用的是你写的 WHERE 条件里用什么操作符、查什么内容、更新频率如何。
比如一个日志表，每条记录带 metadata（小而固定）和 payload（大而稀疏），前者适合 B-tree 或 jsonb_path_ops GIN，后者若常做全文搜，才值得上 GiST + to_tsvector。混合场景下，经常得并存两三种索引——但每个多建一个，写放大就多一分。
- 上线前必跑
EXPLAIN (ANALYZE, BUFFERS)，光看Index Scan不够，重点看Rows Removed by Index Recheck和Buffers数值 - GIN 在高并发写入时容易卡住 WAL，GiST 对 long-running transaction 更敏感——压测时得模拟真实负载，不只是单条查询
- PostgreSQL 14+ 的
pg_stat_progress_create_index能实时看索引构建卡在哪，别等超时才发现是某个巨型 JSON 拖垮了进度
