Redis Geo命令查得快，是因为将经纬度编码为52位geohash整数后存入ZSet，利用跳表实现O(log N)范围查询，而非地理计算；但存在精度衰减、不支持复杂GIS操作、需坐标归一化与去重、GEOSEARCH需显式ASC排序、大数据量须分片等限制。
Geo 命令为什么查得快？不是靠“地理计算”，而是 ZSet 的有序性
Redis 的 GEOSEARCH、GEOPOS 等命令查坐标快，根本原因不是它做了什么空间分割或 R 树索引，而是把经纬度编码成一个 52 位的 geohash 整数，再塞进 ZSet —— 所有操作本质是 ZRANGEBYSCORE 范围查询。
这意味着：它快，是因为跳过了浮点计算和几何判断，全靠整数比较和跳表（skiplist）的 O(log N) 查找。但代价也很明确：精度随距离衰减，且无法做多边形、相交、缓冲区等真正 GIS 操作。
-
geohash编码会损失精度，5km 内误差约 2.4m；50km 内可能偏差超 1km - 所有
GEO*命令都要求经度在-180.0～180.0、纬度在-90.0～90.0，越界直接报错ERR invalid longitude, latitude - 单个 key 最多存 252 个成员（理论值），但实际受内存和跳表性能限制，千万级数据下
ZCARD已明显变慢
用 GEOADD 插入前必须做坐标归一化和去重
直接把原始 GPS 坐标往 GEOADD 里塞，很容易掉进两个坑：一是小数位过多导致 geohash 冗余（Redis 内部只保留 6 位小数）；二是同一设备反复上报，造成大量重复 member，拖慢整个 ZSet 的跳表结构。
推荐做法是插入前统一截断 + 哈希去重：
longitude = round(longitude, 6)
latitude = round(latitude, 6)
member = f"{device_id}:{longitude}:{latitude}" # 避免纯经纬度被不同设备覆盖- 不要用
round(x, 6)后再转字符串拼接——Python 的 float 表示可能引入微小误差，建议用f"{x:.6f}"格式化 - 避免把用户 ID 或设备 ID 当作
member，否则同一设备位置更新会覆盖旧值；应组合唯一标识 + 归一化坐标 -
GEOADD支持批量插入，但单次别超 1000 个，否则阻塞主线程时间过长（尤其在高负载实例上）
GEOSEARCH 返回结果顺序不可靠，需二次排序
GEOSEARCH 默认按 geohash 编码顺序返回，不是按真实距离由近到远。比如搜“附近 5km”，离你 100m 的点可能排在第 200 个，因为它的 geohash 字典序靠后。
要拿到真正最近的 N 个点，必须加 BYRADIUS + SORT 参数，并显式要求 ASC：
GEOSearch myplaces BYRADIUS 116.4 39.9 5 km ASC COUNT 10
- 漏写
ASC就默认按 member 字典序排，跟距离完全无关 -
COUNT是硬限制，不是“取够为止”——如果范围内只有 3 个点，COUNT 10也只返回 3 个 - Redis 7.0+ 支持
WITHDIST，但距离单位固定为请求中指定的（km/m/mi/ft），不能混用
超 100 万坐标时，ZSet 跳表退化明显，该分片就得分片
当一个 key 存了上百万个坐标，ZCARD、ZRANGE、GEOSEARCH 的响应时间会从毫秒级跳到百毫秒级，不是因为 CPU 不够，而是跳表层级变深、缓存局部性变差、内存碎片加剧。
简单扩容不解决问题，必须按空间或业务维度切分：
- 按行政区划切：如
geo:beijing、geo:shanghai，查前先定位城市再查子集 - 按哈希桶切：对
member做hash(device_id) % 16，写入geo:locations:0～geo:locations:15，查时并行 fetch 再合并 - 别依赖
KEYS geo:*扫描——生产环境禁用，改用SCAN配合业务前缀管理
真正难的不是怎么分，而是分完之后的聚合逻辑：比如“查北京上海两地 3km 内所有门店”，得自己做去重和距离重排。这部分没法靠 Redis 自动完成。
