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 场景因写放大反而拖垮吞吐；这些细节比选哪种索引更影响最终体验
