有效，GIN索引对@>查询有效，但必须显式指定jsonb_path_ops或jsonb_ops操作符类；默认GIN索引虽用jsonb_ops支持@>，但省略操作符类易引发歧义，推荐CREATE INDEX ... USING GIN(data jsonb_path_ops)。
GIN 索引对 @> 查询是否有效？
有效，但必须用 jsonb_path_ops 或 jsonb_ops 操作符类创建 GIN 索引，否则 @> 无法走索引。默认的 GIN 索引（即不指定操作符类）底层使用的是 jsonb_ops，它支持 @>、?、?|、?&，但不支持 -> 路径提取的等值查询；而 jsonb_path_ops 更轻量，只支持 @> 和 @?（JSONPath），索引体积更小、构建更快，但不支持键存在性检查（?）。
如何为 @> 查询创建正确的 GIN 索引？
直接在 jsonb 字段上建索引时，显式指定操作符类是关键。漏掉这一步，即使建了 GIN 索引，EXPLAIN 也会显示没用上。
- 推荐写法（兼顾通用性和性能）：
CREATE INDEX idx_data_gin ON orders USING GIN (data jsonb_path_ops);
- 如果还需支持
?或?|，改用：CREATE INDEX idx_data_gin ON orders USING GIN (data jsonb_ops);
- 错误写法（依赖默认行为，易混淆）：
CREATE INDEX idx_data_gin ON orders USING GIN (data);
——虽然 PostgreSQL 会默认用jsonb_ops，但语义不明确，且不同版本或扩展可能影响行为，不建议省略。
@> 查询什么情况下仍可能不走 GIN 索引？
即使索引建对了，PostgreSQL 也可能因统计信息不准、数据分布倾斜或查询模式太“宽”而放弃索引扫描，转为顺序扫描。
- 右操作数含太多键值对（例如
'{"a":1,"b":2,"c":3,...,"z":26}'::jsonb），优化器可能预估索引过滤率低，选择全表扫 - 字段中大量空值或
{}，导致pg_stats中的n_distinct和most_common_vals失真 - 查询中混用非 SARGable 表达式，如
WHERE data @> ... AND lower(data->>'name') = 'foo'，后半部分拖累索引有效性 - 未执行
ANALYZE table_name更新统计信息，尤其在批量导入 JSONB 数据后
实际验证索引是否生效的最小闭环
别只看 EXPLAIN 输出里有没有 Index Scan，要确认它扫的是你的 GIN 索引，且 Index Cond 明确包含 @> 条件。
- 执行：
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE data @> '{"status":"shipped"}'; - 重点看三处：
Index Scan using idx_data_gin、Index Cond: (data @> '{"status":"shipped"}'::jsonb)、Buffers: shared hit=xx（数字小说明缓存友好） - 对比加索引前后的
Execution Time，注意：单次查询时间受缓存影响大，建议多次运行或用EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)排除计时干扰
GIN 索引对 @> 的加速效果高度依赖右操作数结构和数据集基数，简单键值对提升明显，嵌套过深或数组元素匹配（如 @> '{"tags":["urgent"]}'）需额外注意路径设计与索引粒度——这里容易误以为建了索引就万事大吉。
