别指望靠缩小半径“省计算”，真正拖慢 GEOSEARCH 的是结果集数量，不是半径本身；控制结果集大小比调小半径更有效、更可控。
直接结论：别指望靠缩小半径“省计算”，真正拖慢 GEOSEARCH 的是结果集数量，不是半径本身；控制结果集大小比调小半径更有效、更可控。
为什么缩小半径不一定提升性能
Redis 的 GEOSEARCH（或旧版 GEORADIUS）底层对每个成员都执行球面距离计算（Haversine 公式），时间复杂度是 O(N)，N 是地理集合中所有成员数，而非命中数。也就是说，即使你设 BYRADIUS 1km，它仍会遍历整个 ZSET 中的全部点来判断是否在圈内——除非你提前用 ZRANGEBYSCORE 等方式做了预过滤（但原生 GEO 不支持）。所以：
- 半径从 5km 缩到 1km，若集合里本就只有 200 个点，性能差异几乎不可测
- 但如果集合有 50 万点，哪怕半径是 100m，只要没做分桶，它照样扫全量
- 更隐蔽的问题：极小半径（如 50m）反而可能因浮点精度或边界判定导致意外漏点，调试成本上升
真正有效的结果集数量控制手段
与其赌半径，不如明确限制返回条数，并配合业务逻辑剪枝：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 强制加
COUNT：例如GEOSEARCH cities BYRADIUS 3 km COUNT 200 WITHDIST—— 这能显著降低网络传输量和后续客户端处理压力，尤其当你要做加权求和或排序时 - 用
ASC或DESC控制顺序：如果只关心最近的 N 个，加ASC可让 Redis 内部尽早终止距离计算（虽不改变扫描总量，但能减少排序开销） - 前置业务过滤：比如“只查营业中的门店”，先用
SINTER或SCARD判断关联集合大小，再决定是否发起 GEO 查询；避免对空集合或超大集合无差别调用 - 拒绝“全量拿再筛”：不要写
GEOSEARCH ... COUNT 0（即不限量），再在 PHP/Python 里用array_filter做二次筛选——这等于把 Redis 的计算优势全丢掉
半径参数的实际影响：单位与精度陷阱
半径值本身不是瓶颈，但它直接影响结果集分布和后续链路负载：
-
unit必须显式指定：m、km、mi、ft；漏写会导致默认用m，一个BYRADIUS 5可能被当成 5 米而非 5 公里，查不到数据还误以为性能差 - WGS84 坐标系下，Redis 计算存在固有误差（通常 BYRADIUS 100m 和
200m在实际覆盖上可能没区别，但后者结果数可能翻倍 - 高并发场景下，大半径 + 大结果集容易触发 Redis 单线程阻塞，表现为
INFO commandstats中cmdstat_geosearch的usec_per_call突增
什么时候该考虑换方案而不是调半径
当出现以下任一情况，说明单纯调半径已无意义，该动架构了：
-
GEOSEARCH平均耗时 > 5ms 且集合成员 > 10 万 - QPS > 200 且结果集平均 > 100 条，Redis CPU 持续 > 70%
- 业务需要同时支持“1km/3km/10km”多档半径切换——每次切档都要重算全部距离，不如预分桶 + 多 key 查
- 你需要对结果做非距离类排序（如按评分、更新时间），而
GEOSEARCH只能按距离排
这时候，Geohash 分桶 + 应用层合并过滤 或迁移到支持地理索引的专用服务（如 PostGIS、Elasticsearch geo_point）才是正解。半径只是查询条件，不是性能开关。
