基于GeoHash的邻近服务可扩展性存疑：LIKE查询触发全表扫描

首先明确：GeoHash方案本身有其适用场景，但你遇到的全表扫描问题并非方案本身的缺陷，而是索引配置或查询使用方式的问题，下面逐一拆解：

为什么LIKE '9qbwac%'会触发全表扫描？ #

Postgres的B-tree索引默认支持前缀匹配（LIKE 'xxx%'形式），如果你的查询触发了全表扫描，大概率是以下原因之一：

• 索引类型错误：如果给geohash字段创建的是hash类型索引，它不支持前缀匹配，只有btree索引能处理这类前缀查询。
• 统计信息过时：Postgres查询优化器依赖表的统计信息判断执行计划，如果统计信息未更新，优化器可能误判全表扫描比索引扫描更快（比如当匹配的行数占表总量比例较高时）。
• 字段类型不兼容：若geohash存储为非文本类型（比如bytea），前缀匹配的逻辑无法被索引识别。

如何让GeoHash查询用上索引？ #

• 确保创建B-tree索引：

  CREATE INDEX idx_merchants_geohash ON merchants USING btree (geohash);
  

• 更新统计信息：执行ANALYZE merchants;让Postgres获取最新的表数据分布情况，优化器会重新选择更优的执行计划。
• 使用前缀索引优化：如果GeoHash长度固定，可直接针对前缀创建索引，避免LIKE匹配的开销：

  -- 创建前6位的前缀索引
  CREATE INDEX idx_merchants_geohash_prefix ON merchants (substring(geohash FROM 1 FOR 6));
  -- 查询时直接匹配前缀
  SELECT * FROM merchants WHERE substring(geohash FROM 1 FOR 6) = '9qbwac';
  

GeoHash方案的优劣到底如何？ #

优势 #

• 编码逻辑简单，将二维地理坐标转换为字符串，存储和传输成本低。
• 可通过调整前缀长度灵活控制搜索范围（前缀越长，覆盖的地理区域越小）。
• 容易扩展搜索相邻区域：通过计算当前GeoHash的8个相邻格子，可覆盖地理上真正相邻的商家，避免漏判。

劣势 #

• 边界问题：地理上相邻的区域可能对应完全不同的GeoHash前缀，必须额外处理相邻格子才能避免漏查。
• 精度偏差：GeoHash的格子不是严格正方形，不同纬度区域的格子实际地理范围有差异，可能导致搜索精度不均。
• 大范围搜索效率低：当搜索范围较大时，需要匹配多个GeoHash前缀，查询逻辑复杂度上升，性能不如原生空间索引。

更优的替代方案：PostGIS空间索引 #

如果业务对地理查询的精度和性能要求较高，直接使用PostGIS扩展是更稳妥的选择：

1. 安装PostGIS扩展，将商家的经纬度存储为POINT类型（或geography类型，支持球面距离计算）。
2. 创建GIST空间索引：

   CREATE INDEX idx_merchants_location ON merchants USING gist (location);
   

3. 使用ST_DWithin查询指定范围内的商家：

   -- 查询坐标(lon, lat)周围1000米内的商家
   SELECT * FROM merchants
   WHERE ST_DWithin(location, ST_MakePoint(lon, lat)::geography, 1000);
   

空间索引能精准处理地理范围查询，没有GeoHash的边界问题，数据量越大，性能优势越明显。

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