SQL 空间索引（PostGIS）的 GiST vs SP-GiST vs BRIN 的几何查询性能对比

gist是postgis几何查询最稳妥的默认选择，支持所有几何类型和空间谓词，对数据分布不敏感；sp-gist仅适用于高精度点且knn为主的有序轨迹场景；brin仅在空间数据物理聚类时有效。

GiST 是几何查询最稳妥的默认选择

PostGIS 的空间索引里，GiST 不是“历史遗留”，而是当前绝大多数几何查询场景下真正扛得住的通用方案。它支持所有几何类型（点、线、面、集合）、全部空间谓词（ST_Intersects、ST_Contains、ST_DWithin 等），且对数据分布不敏感——哪怕你的 geometry 列里混着全球坐标系的国家边界和城市内 10 米精度的传感器点，GiST 也能稳定收敛。

常见错误现象：CREATE INDEX ON tbl using SP-GiST (geom) 后发现 ST_Intersects 慢得离谱，甚至不走索引——因为 SP-GiST 默认只加速 ST_Equals 和某些特定距离查询，不覆盖主流谓词。

• 新建表或不确定数据特征时，无脑用 CREATE INDEX ON tbl USING GIST (geom)
• 如果已有 GiST 索引但查询仍慢，优先检查是否漏了 ANALYZE tbl —— PostGIS 查询计划严重依赖统计信息
• GiST 索引体积通常比 BRIN 大 5–10 倍，但换来的是一致的响应延迟；别为了省磁盘赌 BRIN 在小范围查询里的表现

SP-GiST 只在极少数结构化几何场景下有优势

SP-GiST 不是 GiST 的升级版，它是为“可递归分解+强局部性”的数据设计的。典型适用场景：全是高精度点（比如 GPS 轨迹点），且按时间/顺序批量插入、查询常带 ORDER BY geom $point LIMIT N（KNN）。

使用场景限制很硬：SP-GiST 对 Polygon 或 MultiLineString 支持弱，ST_Within 基本不走索引；官方文档明确说它“not suitable for general-purpose spatial indexing”。

• 只在满足以下全部条件时考虑：geometry 列 95% 以上是 POINT；数据按空间接近性有序写入（如轨迹流）；查询以 KNN 为主（ 操作符）
• 必须显式启用 KNN 支持：CREATE INDEX ON tbl USING SPGIST (geom) WITH (fillfactor = 90)，否则连 都不加速
• 一旦表里混入几个大面对象，SP-GiST 效率断崖下跌，且 VACUUM 开销远高于 GiST

BRIN 仅适用于按物理存储顺序天然聚类的大表

BRIN 索引大小可能只有 GiST 的 1%，但它完全依赖数据在磁盘上的物理排列。如果你的表是按时间字段 INSERT，而空间上也恰好是“同一区域的记录集中写入”（比如按城市分区批量导入），那 BRIN 才可能生效。

常见错误现象：EXPLAIN 显示用了 BRIN 索引，但实际执行扫描了 80% 的块——因为几何数据在磁盘上是随机分布的，每个 range 的 min/max bbox 几乎全覆盖整个地理范围，索引失去过滤能力。

• 建 BRIN 前先确认：select pg_relation_size('tbl') / (SELECT count(*) FROM tbl) 算出平均行大小，再看 SELECT * FROM pg_stats WHERE tablename = 'tbl' AND attname = 'geom' —— 如果 most_common_vals 为空且 correlation 接近 0，直接放弃
• BRIN 的 pages_per_range 参数不能乱调：设太小（如 4）导致索引膨胀；设太大（如 128）则过滤粒度太粗；从 16 开始试，配合 EXPLAIN (ANALYZE, BUFFERS) 观察 shared hit 和 read 比例
• 即使生效，BRIN 也几乎不加速 ST_DWithin 这类需要精确边界计算的查询，只对“查某矩形框内有哪些记录”这类粗筛有点用

真实性能差异往往取决于查询模式，不是索引类型本身

很多人测完 GiST vs BRIN 的 ST_Intersects 延迟，就急着下结论。但实际生产中，一个查询快不快，70% 取决于你有没有把空间过滤写在 WHERE 最前面、是否避免了 ST_Transform 在索引列上运行、有没有给 JOIN 条件加空间约束。

容易被忽略的点：GiST 索引对 ST_DWithin(geom, 'POINT(...)', 100) 加速明显，但若写成 ST_DWithin(ST_Transform(geom, 4326), ...)，索引直接失效——因为函数包装破坏了操作数直传。

• 强制走索引的最低成本方式：确保 WHERE 子句左侧是裸列名，右侧是常量或绑定参数，中间是原生空间操作符（&&、、ST_Intersects）
• 用 EXPLAIN (ANALYZE, BUFFERS) 时重点看两行：Index Scan using ... on tbl 是否出现，以及 Rows Removed by Index Recheck 是否远大于 0（说明索引精度不够，回表开销大）
• 没有银弹——GiST 在小表上可能比全表扫还慢；BRIN 在 OLTP 场景因写放大反而拖垮吞吐；这些细节比选哪种索引更影响最终体验