GeoHash 搜索机制详解：从编码原理到实际应用

摘要

本文详细解析了 GeoHash 搜索的核心机制和工作原理。GeoHash 通过将经纬度坐标二进制化并交织成 Morton code，再 Base32 编码为字符串，实现将二维空间问题转换为一维字符串索引。搜索时，首先将查询点编码并截取合适长度的前缀，然后查询中心格子及其周围8个相邻格子（共9个格子）以解决边界问题，通过数据库前缀查询高效获取候选集，最后进行精确距离过滤。这种方案相比传统经纬度范围查询，能利用B树索引高效处理二维空间查询，为空间索引提供了优化思路。

好问题，GeoHash 搜索的核心思路确实不直观，用一个具体例子拆解一下。

先理解 GeoHash 编码是怎么回事

经纬度是两个浮点数，GeoHash 把它们都二进制化之后交织成 Morton code，然后 Base32 编码成字符串：

纬度  39.92  → 二进制  10110...
经度 116.38  → 二进制  11001...
交织           → 11100110...
Base32         → "wx4g0"

关键性质：字符串越长，精度越高，表示的地理范围越小。

"wx"       → 大约 1300km × 1300km 的方格
"wx4"      → 大约 156km × 156km
"wx4g"     → 大约 40km × 20km
"wx4g0"    → 大约 5km × 5km
"wx4g0ec"  → 大约 150m × 150m

截取相同前缀 = 在同一个方格里。

搜索的实际机制

搜索"北京天安门附近 5km 内的餐厅"，步骤是这样的：

第一步：把查询点编码，截取合适长度的前缀

5km 对应精度大约是 4 位 GeoHash，天安门的编码是 wx4g，意味着"在这个 40km × 20km 方格里的所有点"。

第二步：取这个格子 + 周围 8 个相邻格子，共 9 个格子

这是 GeoHash 搜索里最核心、也最容易被忽略的一步。

原因是边界问题——两个物理上紧挨着的点，如果恰好在方格边界两侧，它们的 GeoHash 前缀会完全不同：

A 点  → "wx4g..."   在格子内
B 点  → "wx4f..."   紧挨着 A，但跨了边界，前缀不同

如果只查 wx4g 前缀，B 永远找不到。所以必须同时查询中心格子和它周围的 8 个邻居格子：

wx4d  wx4e  wx4s
wx4g  [wx4u]  wx4v    ← 中括号是查询点所在格
wx46  wx47  wx4k

这 9 个格子的编码是可以直接通过位运算从中心格子推算出来的，不需要查表。

第三步：对这 9 个前缀做数据库查询

SELECT * FROM restaurants
WHERE geohash LIKE 'wx4g%'
   OR geohash LIKE 'wx4u%'
   OR geohash LIKE 'wx4v%'
   -- ... 另外 6 个格子

因为 GeoHash 是字符串，数据库对 LIKE 'wx4g%' 这种前缀查询可以直接走 B 树索引，效率极高。

第四步：精确过滤

第三步拿回来的是一个候选集，里面的点都在这 9 个方格里，但方格是矩形，"附近 5km"是个圆，所以最后还要对每个候选点算一次真实距离（Haversine 公式），把超出半径的点过滤掉。

整个流程图

查询点 (lat, lng)
    ↓ 编码 + 截取前缀
中心格子 "wx4g"
    ↓ 推算邻居
9 个格子前缀
    ↓ 数据库前缀查询（走索引，极快）
候选集（几十到几百个点）
    ↓ 精确距离计算（Haversine）
最终结果

为什么这个方案好

传统的经纬度范围查询是：

WHERE lat BETWEEN 39.87 AND 39.97
  AND lng BETWEEN 116.33 AND 116.43

这需要在 lat 和 lng 两个字段上各走一次索引，数据库很难同时高效利用两个索引，数据量大时会很慢。

GeoHash 把二维问题压成一维字符串，一个 B 树索引就能高效处理，这是它的核心价值所在。

对 kwcc 的启发

如果以后 kwcc 要做 widget 命中检测（点击坐标命中哪个组件），本质上是同一个问题：二维空间里的点查询。Morton code 做索引 + 邻居格子扩展这套思路完全可以搬过来，只是坐标换成了屏幕像素，"距离"换成了包含关系。不过 kwcc 现在 widget 数量还小，这是以后的事。