咱们直接点破核心问题：你创建的索引和查询用的表达式完全不匹配，导致PostgreSQL没法利用这个GIN索引。

具体来说：

• 你建索引用的是data->'key'，这个->操作符针对jsonb列返回的是jsonb类型的值
• 但你的查询条件写的是data->>'key' = 'xxx'，->>操作符返回的是text类型的字符串

这俩表达式的类型和结构都不一样，优化器自然不会把它们关联起来，只能老老实实走顺序扫描。从你的执行计划看，表有7万多行，顺序扫描确实慢，所以解决表达式匹配是关键。

给你三个实用方案，按需选择：

方案1：改查询语句，匹配索引的表达式 #

把查询条件改成和索引一致的写法，把右边的字符串转成jsonb类型就行：

explain (analyze, buffers) 
select * from t3 where data->'key' = 'ZGJVcGdyYWRlXzIwMTcwNzE0ZGVkdXBsaWNhdGVEYXRh'::jsonb;

这样优化器一眼就能认出可以用你之前建的t3_index，直接走索引扫描。

方案2：建适合text查询的索引（推荐） #

如果你习惯用->>的text查询方式，不如直接建个对应类型的索引，分两种情况：

情况A：需要模糊匹配？用GIN+trgm操作符 #

如果之后还要做模糊查询（比如LIKE '%xxx%'），就建带gin_trgm_ops的GIN索引：

CREATE INDEX t3_key_text_gin ON t3 USING GIN ((data->>'key') gin_trgm_ops);

这个索引既能支持精确匹配，也能搞定模糊查询，灵活性拉满。

情况B：只做精确匹配？用B-tree索引更高效 #

如果你的查询都是精确等于的场景，B-tree索引的性能比GIN更好，因为它更轻量化：

CREATE INDEX t3_key_text_btree ON t3 USING BTREE ((data->>'key'));

建完之后，你原来的查询语句不用改，优化器会自动用上这个B-tree索引。

方案3：强制用索引（不推荐，应急用） #

实在万不得已的话，可以强制优化器走索引，但不建议常规这么用——毕竟优化器的选择是基于统计信息的，强制索引可能在数据量变化时掉链子。比如：

-- PostgreSQL 11+支持的语法
explain (analyze, buffers) 
select * from t3 
where data->>'key'='ZGJVcGdyYWRlXzIwMTcwNzE0ZGVkdXBsaWNhdGVEYXRh'
INDEX t3_index;

-- 或者临时关闭顺序扫描（会话级生效）
SET enable_seqscan = off;
select * from t3 where data->>'key'='ZGJVcGdyYWRlXzIwMTcwNzE0ZGVkdXBsaWNhdGVEYXRh';
SET enable_seqscan = on; -- 用完记得改回来

• 跑一遍ANALYZE t3;更新表的统计信息，确保优化器能拿到最准确的数据分布，做出最优选择。
• 对jsonb单键的精确匹配来说，B-tree索引通常比GIN索引更快，GIN更适合数组、多值或者复杂json结构的查询场景。

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