PostGIS中ST_DWithin有时不使用索引的问题咨询

你遇到的这个情况完全是PostGIS和PostgreSQL优化器的预期行为，咱们来拆解一下背后的原因：

1. 第一个查询慢100倍的核心原因 #

当你对Geometry(4326)类型的字段使用ST_DWithin，并传入米作为距离单位+use_spheroid=true时，PostGIS会自动把Geometry对象转换为Geography类型来进行球面距离计算——但你的空间索引是针对Geometry类型创建的，转换后的Geography对象无法匹配这个索引，因此数据库只能走全表顺序扫描（看执行计划里的Seq Scan on cars），这就是速度骤降的根本原因。

2. 第二个查询能用上索引的原因 #

当你传入的距离单位是度（和SRID4326的坐标单位一致）时，PostGIS会直接在平面坐标系上计算笛卡尔距离，这时候你的cars_location_index（Geometry类型的空间索引）就能被正常调用。执行计划里的Bitmap Index Scan on cars_location_index也印证了这一点，索引快速过滤出候选数据，所以执行速度极快。

3. 距离过小/过大时回退到顺序扫描的原因 #

PostGIS的空间索引是基于R树结构的，它通过边界框（Bounding Box）的交集来快速缩小查询范围。当你的查询距离：

• 过小（比如<0.4度）：生成的查询边界框太小，过滤掉的数据极少，索引查找的开销反而比全表扫描更高；
• 过大（比如>45度）：生成的边界框几乎覆盖整个地球，几乎所有数据都会被命中，优化器会认为走全表扫描更高效。

这两种情况下，PostgreSQL的优化器都会自动选择顺序扫描，属于正常的优化决策。

4. 改成Geography类型后问题解决的原因 #

Geography类型本身就是为球面地理计算设计的：

• 它的默认单位是米，不需要手动转换单位，语义更直观；
• 它的空间索引是基于球面边界框构建的，无论你设置use_spheroid=true/false，还是查询距离的大小，PostGIS都能直接利用索引做快速过滤，不会出现类型转换导致索引失效的问题，因此查询始终能用上索引。

实践建议 #

• 如果你的业务是真实地理场景的距离查询（比如周边搜索），优先使用Geography类型，它能避免单位混淆和索引失效的问题；
• 若必须使用Geometry(4326)，务必保证查询距离的单位和SRID一致（即度），同时尽量让查询的边界框大小适中，让优化器认为索引的收益大于开销；
• 若需要在Geometry类型上做球面距离计算，可以显式使用ST_Distance_Sphere/ST_Distance_Spheroid，但要注意这类计算无法直接利用Geometry索引，性能会不如Geography类型的查询。

内容的提问来源于stack exchange，提问作者Ivan Yurov