用GEOADD批量写入+GEORADIUS带COUNT和ASC查询是最稳低延迟组合；但海量点位下卡顿源于Geohash编码层级与ZSET范围扫描的隐式开销。
直接结论：用 GEOADD 批量写入 + GEORADIUS 带 COUNT 和 ASC 查询，是当前最稳的低延迟组合；但海量点位下，真正卡顿的不是命令本身，而是 Geohash 编码层级和 ZSET 范围扫描的隐式开销。
为什么 GEOADD 批量写入比逐条快得多
Redis 的 GEOADD 单次可带多个 longitude latitude member 三元组，底层会复用同一套 Geohash 编码逻辑，避免重复解析与浮点转换。实测百万级点位，用 pipeline 包裹 100 条/批的 GEOADD，比逐条执行快 8–12 倍。
- 别漏掉
NX或XX选项：如果只是初始化数据，加NX可跳过已存在 member 的校验，减少 CPU 消耗 - 经度纬度必须为字符串数字（如
"116.404"），不能是科学计数法或带空格，否则整批失败并报ERR invalid longitude, latitude - 成员名
member含空格或特殊字符时，必须用双引号包裹，比如"shenzhen north station"，否则 Redis 会截断解析
GEORADIUS 查询慢？先检查这三点
当 GEORADIUS 响应明显变长（>50ms），大概率不是数据量问题，而是查询参数触发了全量 Geohash 前缀扫描。
- 半径单位必须显式指定：传
1000默认是米，查 1km 得写1 km，单位错会导致 Redis 扩大扫描范围（例如误按 1 米去扫，实际要扫 1000 倍区域） - 中心点经纬度小数位数要和
GEOADD时一致：存的是114.057868，查时用114.05会因 Geohash 解码层级下降，漏掉本该命中的点 -
COUNT不是“限制返回数量”，而是“限制扫描候选数”：设COUNT 10并不等于只查最近 10 个，而是最多从 Geohash 邻近 10 个 bucket 里捞点——若这些 bucket 里没够 10 个有效点，结果就少于 10；想确保取满，得设稍大些（比如 50），再在应用层截断
ZSET 底层结构决定了它不适合“超细粒度距离排序”
GEORADIUS 返回结果默认按距离升序，但这个排序不是靠实时计算 Haversine 公式得出的，而是依赖 Geohash 的前缀局部性 + ZSET score 排序的近似。这意味着：
- 两个点 Geohash 前缀相同（比如都落在同一个 52 位编码的前 40 位），Redis 就认为它们足够近，不再精细算距离；所以高密度城区（如深圳南山）可能出现“明明 A 更近，却排在 B 后面”的情况
- 真要严格按球面距离精确排序，得用
WITHDIST拿到距离值后，在客户端做二次排序——但代价是网络多传一次数据、应用层多一次 O(n log n) 计算 - 别对
GEORADIUS结果直接ZRANK：ZSET 的 score 是 Geohash 值，不是距离，ZRANK返回的是 Geohash 数值序，和地理远近无关
最容易被忽略的是：Geohash 截断发生在编码阶段，不是查询阶段。你存进去的经纬度一旦精度丢失（比如只保留 2 位小数），后续所有 GEODIST 和 GEORADIUS 都基于这个失真坐标算——Redis 不提醒，也不修复，它只忠实地执行编码和匹配。
