上周三凌晨两点，服务器报警群炸了。不是代码崩了，是“附近的人”功能响应时间飙到了8秒。用户骂娘，老板催命。那一刻我才意识到，之前为了省事，直接把所有地理围栏逻辑塞进了数据库，以为Geo MySQL redis能通吃，结果被现实狠狠打脸。
很多人觉得，既然Redis有GEO模块，MySQL也有空间索引，为啥还要折腾？因为场景不同，硬凑一起就是灾难。我见过太多团队，初期为了快，全量数据扔进Redis，结果内存爆仓，或者为了省钱，全量查MySQL，结果QPS一高，数据库直接锁死。真正的痛点在于：你怎么平衡实时性、成本和查询复杂度？
第一步，别把鸡蛋放在一个篮子里。我的做法是分层。核心热点数据，比如城市中心区、热门商圈，必须留在Redis里。这些区域用户密度大，请求频率极高，Redis的O(1)或O(log N)查询速度是MySQL没法比的。我算过一笔账，在一线城市核心区，每秒可能有上千次“附近商家”查询，如果这时候去扫MySQL的B-Tree，CPU占用率瞬间就能到90%以上。这时候，用Redis的GEOADD和GEORADIUS，响应时间能压到5毫秒以内。
第二步，冷数据别浪费钱。对于偏远地区、低频访问的用户数据，直接存MySQL。MySQL的空间索引虽然慢一点，但胜在便宜、稳定，而且支持复杂的事务和关联查询。比如，你要查“附近3公里内评分4.5以上的餐厅”，这种带条件过滤的查询，Redis处理起来很吃力，它擅长的是纯距离排序。这时候，MySQL的WHERE distance < 3 AND rating > 4.5 才是王道。
第三步，同步机制要靠谱。很多团队在这里翻车。Redis和MySQL的数据不一致，导致用户看到的商家明明在线，却查不到。我采用的是“先写Redis，异步刷MySQL”的策略。利用Canal监听MySQL binlog，或者直接在业务代码里双写。注意，双写要有重试机制，网络抖动是常态。我见过一个案例，某外卖平台因为双写失败，导致商家状态不同步，用户点了单却显示商家已关门，投诉率直线上升。所以，务必加上日志记录和监控告警，一旦同步失败，立刻报警。
第四步，边界情况要特殊处理。比如跨区查询，或者超大半径查询。Redis的GEORADIUS在半径超过50公里时，性能会急剧下降，因为需要扫描更多节点。这时候，可以考虑分片查询，或者降级为MySQL查询。我之前的项目里，就有一个功能，用户设置50公里半径，结果Redis查询超时，直接卡死。后来改成：半径<10公里走Redis，>10公里走MySQL，瞬间问题解决。
真实案例数据：我们优化后，核心查询QPS从2000提升到15000，数据库CPU使用率从85%降到30%。当然，这不是魔法，是架构设计的胜利。Geo MySQL redis 并不是简单的叠加，而是各司其职。
最后说句掏心窝子的话，别迷信单一技术。技术选型没有银弹，只有最适合当前业务阶段的方案。初期为了快，可以激进一点；后期为了稳，必须精细化。如果你正在为地理位置服务头疼，或者不确定自己的架构是否合理，不妨聊聊。很多时候，瓶颈不在代码，而在设计思路。
