GIN索引适合数组、JSONB、全文检索等多值字段场景，因其为每个元素建倒排条目，能高效支持@>、@@等操作；但写入慢、体积大、不支持ORDER BY，切勿滥用在普通字符串字段上。
gin 索引适合什么场景？为什么别乱用
GIN（Generalized Inverted Index）专为数组、JSONB、全文检索等“多值字段”设计。它把每个元素单独建倒排条目，查 tags @> Array['pg'] 或 to_tsvector('text') @@ to_tsquery('search') 时效率高。
但代价明显：写入慢、体积大、不支持 ORDER BY 加速。
常见错误是给普通字符串字段建 GIN——比如 name VARCHAR 上建 GIN (name)，结果查询没变快，INSERT 却拖慢 3 倍。
- 只在明确需要「包含」「重叠」「全文匹配」时用 GIN
- 数组字段优先用
GIN (col)，JSONB 推荐GIN (col jsonb_path_ops)（节省空间，但不支持@>以外的操作符） - 避免对单值字符串字段建 GIN；改用 B-tree 或表达式索引（如
LOWER(name)）
GiST 和 SP-GiST 都能加速几何/范围查询，怎么选
GiST 是通用框架，支持 R-tree（几何）、B-tree-like（范围）、KNN 搜索；SP-GiST 是它的“轻量分支”，专注非平衡树结构，比如地理分区或前缀树。
典型踩坑：用 GiST 加速 IP 地址查询（inet 类型），却忽略 SP-GiST 对 inet 的原生优化。实测中，SP-GiST 在 ip 这类前缀匹配上内存更少、构建更快。
- 几何类型（
point,box）优先 GiST；范围类型（tsrange,numrange）两者都行，但 GiST 支持更多操作符 -
inet/cidr字段用 SP-GiST 更合适：CREATE INDEX ON t using SPGIST (ip) - GiST 支持 KNN（
操作符），SP-GiST 不支持；需要最近邻搜索时必须选 GiST
BRIN 索引不是“低配版 B-tree”，它只在特定数据分布下有效
BRIN（Block Range INdex）不存每行键值，而是记录每个页块（block range）的 min/max 值。所以它极省空间、创建飞快，但只对「天然有序」或「按时间/ID 批量写入」的数据有用。
你如果给一个随机插入的 user_id UUID 字段建 BRIN，基本等于没建——因为每个块的 min/max 几乎无区分度，查询时仍要扫大量块。
- 数据按索引列物理排序（如按
created_at插入日志表），BRIN 效果接近 B-tree，体积却只有 1% - 表大小 > 数 GB、查询常带时间范围过滤（
WHERE created_at BETWEEN ...）时优先试 BRIN - 别在
UPDATE频繁的字段上建 BRIN；块内数据失序后，BRIN 的跳过率会断崖下跌
Bloom 索引适合做“存在性快速否定”，但不能替代精确索引
Bloom 是概率型索引，只回答“这个值很可能不存在”，误判率可调（默认 0.01）。它对等值查询（=）有加速作用，尤其适合宽表中多个低选择性字段联合过滤。
但它不存原始值，也不支持 IS NULL、范围、排序——甚至不能保证 = 查询一定快：如果误判率高或缓存未命中，反而比顺序扫描还慢。
- 仅用于高频等值查询 + 多列组合（如
(status, region, category)），且单列选择性不高（重复值多） - 必须配合
WHERE中所有索引列都出现，否则 Bloom 完全不触发 - 创建时务必设合理
Length（默认 5）和col1,col2,...顺序；列顺序影响误判率，高频过滤列放前面
实际选型时，最常被忽略的是数据写入模式和物理顺序——索引再 fancy，数据在磁盘上乱成一团，BRIN 和 Bloom 就直接失效；而 GIN/GiST 的开销，往往在批量导入时才暴露出来。