GEO 看起来像 Redis 里单独的一类地理索引，但它的根其实扎在 ZSet 里。经纬度会被编码成可排序的 geohash 分数，再利用有序集合做候选范围检索。
这解释了一个常见边界：Redis GEO 很适合查附近的人、附近门店、半径内候选点；但它不是完整 GIS，不擅长复杂多边形、道路距离和空间关系分析。
先把机制边界说清楚
这一篇只讨论 Redis GEO 的索引思路和查询边界，不把它替代 PostGIS、Elasticsearch Geo 或地图服务。
整体路径
上面这张图先把主线铺开：经纬度 -> geohash score -> 范围候选 -> 精确过滤。所以 GEO 的代价要看查询半径、返回量和底层 ZSet 规模，而不是只看命令。
底层机制
- 写入位置时，Redis 会把经纬度编码成 geohash，并作为 ZSet 分数保存。
- 范围查询先根据目标区域找到候选 geohash 范围，再计算真实距离过滤。
GEOSEARCH比老的GEORADIUS更适合作为现代命令入口。- 返回数量和半径直接影响扫描范围，查询越宽，候选越多。
这些机制放在一起看，就能理解 GEO 为什么能高效做附近查询，以及为什么大半径、深翻页会变慢。
取舍与边界
GEO 的优势是轻量和低延迟，弱点是地理语义有限。它是附近检索，不是空间数据库。
典型问题：用机制化例子排查
- 附近门店、同城用户、车辆粗定位可以用 GEO 做候选召回。
- 查询必须限制半径和
COUNT，不要给用户一个无限地图拖拽范围。 - 复杂边界、多边形围栏和道路距离交给 GIS 系统，Redis 只做缓存或候选层。
- 按城市或业务区域拆 key，避免全球点位混在一个 ZSet 里。
收束：一句判断
Redis GEO 的本质，是用 ZSet 做了一层足够快的地理候选索引。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
