哎哟，最近好多兄弟私信问我，说搞那个“附近的人”或者“基于地理位置搜索”的功能，头都大了。以前用 MongoDB 的 GeoJSON 挺顺手，现在公司非要用 MySQL，还要求高性能，这咋整？别急，今天咱就掰开揉碎了聊聊 geo mysql 怎么落地，不整那些虚头巴脑的理论，直接上干货，保证你看完能直接去改代码。
首先得纠正一个误区，很多人以为 MySQL 5.7 之前没法搞空间索引，那是老黄历了。现在主流用的都是 8.0 版本，或者至少是 5.7+，支持 Spatial Index 是标配。但是！支持归支持，你要是直接拿经纬度存成 float 然后算欧几里得距离，那查询慢得能让你怀疑人生。为啥？因为地球是圆的，平面几何公式在球面上根本不准，而且没有索引加持，全表扫描谁受得了？
咱们第一步，建表结构得讲究。别偷懒，直接用 DECIMAL(10,6) 存经纬度，精度够高，还方便后续计算。然后，最关键的一步，加空间索引。比如你有个用户表，里面有个 point 字段，类型是 POINT。你得执行 ALTER TABLE users ADD SPATIAL INDEX idx_point (point); 这一步不做，后面全是白搭。注意啊，空间索引对 B-Tree 索引是两码事，别混了。
第二步，查询语句怎么写？这是重灾区。很多新手喜欢用 ST_Distance_Sphere，这函数在 MySQL 5.7+ 是有的，它算的是球面距离，比 ST_Distance 准多了。但是！如果你数据量百万级，光靠这个函数过滤，还是得全表扫。所以，得配合范围查询。比如你要找 1 公里内的人，先算出经纬度的大致矩形范围。假设中心点是 (lat, lng)，半径 R 公里，你可以粗略估算 delta_lat 和 delta_lng。虽然这不精确，但用来做第一层过滤，能筛掉 99% 的数据，剩下那 1% 再用 ST_Distance_Sphere 精算。这样既快又准。
举个例子，SQL 大概长这样：SELECT * FROM users WHERE ST_Distance_Sphere(point, POINT(116.40, 39.90)) < 1000; 看着挺简单，但如果你不加空间索引，或者没做范围预处理，数据库引擎就得把每一行都拿出来算一遍，CPU 直接爆满。我有个朋友之前就是这么干的，线上直接报警，后来加了索引，查询时间从 2 秒降到 20 毫秒，这差距，啧啧。
再说说数据对比。有人拿 Redis 的 Geo 模块比，说 Redis 快。确实，Redis 是内存数据库，读写肯定快，但持久化和数据量上限是硬伤。如果你的用户量千万级，还得存历史轨迹，MySQL 更靠谱。而且，MySQL 的事务性、关联查询能力，是 Redis 没法比的。对于大多数中小项目，geo mysql 完全够用，没必要为了炫技上分布式方案。
还有一个坑，就是索引失效。你如果在 WHERE 条件里对点字段做了函数运算，比如 ST_X(point) > 100，那空间索引就废了，变回全表扫描。记住，索引字段必须是原始字段，别折腾它。
最后给个结论：搞 geo mysql 附近的人功能，核心就三点：1. 用 DECIMAL 存坐标；2. 建 SPATIAL INDEX；3. 先范围过滤再精算距离。别整那些花里胡哨的，按这个套路走，稳如老狗。要是你还纠结性能问题，那多半是索引没建对，或者查询逻辑太复杂。
对了，记得测试环境多跑几遍，看看 EXPLAIN 执行计划，确认 idx_point 真的被用上了。要是显示 type 是 ALL，那赶紧回去检查 SQL 写法。别等上线了再哭，那时候运维骂你得可难听了。
总之，技术这东西，别怕麻烦，基础打牢了，后面省下的时间能多陪你陪家人吃好几顿火锅。希望这篇 geo mysql 的实战分享能帮到你，要是还有啥不懂的，评论区见，咱接着唠。毕竟，代码是写给人看的，顺便给机器执行，对吧？
