上周有个做本地生活服务的老板找我喝茶，一脸愁容。他说他们平台有三十万条商户数据，用户搜“附近咖啡馆”，页面加载要三秒以上。老板急得跳脚，觉得是服务器配置不够，想直接加钱上云。我拦住了他，打开后台看了一眼查询日志，心里大概有数了。

这根本不是硬件问题，是查询逻辑太笨。很多老板以为只要上了数据库就能快，其实不然。如果还在用简单的经纬度字段做范围查询，或者更离谱的，把坐标存在字符串里，那数据库每次都要全表扫描。三十万条数据，扫一遍确实得几秒。这时候你加再好的服务器，也是治标不治本。

真正的解法，是用对 mysql geo索引 技术。

咱们得先搞清楚，为什么普通索引不行。地理空间数据是二维的，经度和纬度。普通的B+树索引是一维的，它擅长处理范围，比如ID大于100小于200。但经纬度呢？你在一个矩形区域内搜索，B+树索引效率极低，因为它无法利用空间局部性。这就好比你在一堆乱糟糟的纸条里找特定区域的名字，效率当然低。

这时候，GeoHash或者R-Tree索引就派上用场了。我推荐大家用MySQL自带的空间索引，也就是基于R-Tree的结构。它能把空间数据划分成树状结构，查询的时候，只需要遍历几个节点就能定位到目标区域，而不是扫描全表。

举个真实的例子。我之前帮一家连锁餐饮店优化过他们的会员定位功能。他们之前是用两个浮点数字段存经纬度，查询附近五公里内的用户，每次都要跑十几秒。后来我们给这两个字段加了联合索引没用，因为联合索引对空间查询帮助不大。我们改用了MySQL的POINT类型，并建立了SPATIAL INDEX。

改完之后，查询时间从12秒降到了0.05秒。老板当时差点没坐住椅子。这就是 mysql geo索引 的威力。它不是魔法，是数据结构的选择对了。

当然，这里有个坑，很多同行没讲清楚。MySQL 5.7之前，空间索引只支持InnoDB引擎的特定版本，而且对地理数据类型的支持有限。如果你还在用老版本，建议升级。另外，导入数据的时候，要注意坐标系的统一。大多数国内地图用的是GCJ-02或者BD-09，而MySQL默认支持WGS-84。如果不转换，查出来的距离会有几百米的偏差，这在本地服务里是致命的错误。

还有一点，别迷信全量索引。如果你的数据量超过百万级，且并发极高，单纯靠数据库可能还是吃力。这时候可以考虑将热点数据缓存到Redis，利用Redis的Geo模块。Redis的Geo底层也是基于ZSet和GeoHash实现的，查询速度更快，适合做实时性要求极高的场景，比如打车软件的附近车辆显示。但对于历史数据归档、复杂的地理范围统计，MySQL的空间索引依然是性价比最高的选择。

很多老板在选型时，喜欢问“哪个最快”。其实没有绝对的最快，只有最适合。如果你的业务主要是查附近的人、附近的店，且数据量在千万以内， mysql geo索引 绝对是你该优先考虑的方案。它不需要引入额外的中间件，维护成本低，开发简单。

最后给个实操建议。在建表时，直接使用GEOMETRY或POINT类型，不要存字符串。创建索引时，确保引擎是InnoDB，并显式声明SPATIAL INDEX。查询时，使用ST_Distance_Sphere函数计算距离，注意这个函数在MySQL 5.7.6之后才支持，之前的版本可以用ST_Distance，但结果单位可能不同，务必查文档。

别等系统崩了再优化。现在就去查查你的SQL日志，看看有没有那些慢得离谱的空间查询。优化好了，用户体验上去了，老板的钱袋子也鼓了。这比盲目加服务器靠谱多了。如果有具体的表结构拿不准，欢迎随时交流，咱们一起看看怎么改最省事。