不能。MySQL 8.0.17前ST_Distance_Sphere()不走R-Tree索引，需用ST_Intersects+ST_MakeEnvelope粗筛再精算；ST_DWithin仅支持平面坐标；GeoHash+B-Tree是更稳定替代方案。
MySQL 的 POINT 字段和 ST_Distance_Sphere() 能直接用 R-Tree 索引吗？
不能。这是最常被误解的一点：即使你把经纬度存成 POINT 类型、加了 SPATIAL 索引，ST_Distance_Sphere() 在 MySQL 8.0.17+ 之前根本**不走空间索引**——它会全表扫描。MySQL 8.0.17 起才支持在 WHERE 子句中用 ST_DWithin() 触发 R-Tree 索引加速，但前提是单位一致且用的是平面坐标（如 Web Mercator），不是球面距离。
-
ST_Distance_Sphere()是计算真实球面距离的函数，但优化器无法下推到空间索引上 -
ST_Contains()、ST_Intersects()、ST_DWithin()（仅限平面坐标）才能有效利用SPATIAL索引 - 如果你的字段是
POINT但没建SPATIAL索引，或者建了但查询没用对函数，R-Tree 彻底闲置
怎么写一个能走 R-Tree 索引的“附近 5km”查询？
核心思路：先用矩形范围快速过滤（ST_MakeEnvelope + ST_Intersects），再用 ST_Distance_Sphere() 精排。R-Tree 只负责第一步的粗筛，避免算全部点的距离。
- 把目标点转成
POINT：ST_PointFromText('POINT(116.48 39.92)') - 用
ST_Distance_Sphere()算出 5km 对应的近似经纬度偏移（比如纬度方向约 0.045°，经度方向需按纬度缩放），生成包围矩形：ST_MakeEnvelope(116.435, 39.875, 116.525, 39.965, 4326) - 查询必须写成：
WHERE ST_Intersects(location, ST_MakeEnvelope(...))，其中location是带SPATIAL索引的POINT字段 - 最终排序或过滤仍需
ST_Distance_Sphere(location, @point) ，但这一步只作用于矩形内几百条记录，不是全表
SELECT id, name, ST_Distance_Sphere(location, ST_PointFromText('POINT(116.48 39.92)', 4326)) AS dist
FROM poi
WHERE ST_Intersects(location, ST_MakeEnvelope(116.435, 39.875, 116.525, 39.965, 4326))
AND ST_Distance_Sphere(location, ST_PointFromText('POINT(116.48 39.92)', 4326)) <h3>为什么 <code>SPATIAL</code> 索引有时比普通 B-Tree 还慢？</h3><p>R-Tree 不是万能加速器。它对“小范围高密度”场景友好，但对“大范围稀疏分布”或“大量重叠区域”的查询反而可能退化——因为索引节点覆盖太广，实际仍要回表校验大量记录。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill10796" title="MySQL8 CRM Schema Design Expert"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="MySQL8 CRM Schema Design Expert" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill10796" title="MySQL8 CRM Schema Design Expert" class="overflowclass">MySQL8 CRM Schema Design Expert</a>
<p class="overflowclass">面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。</p>
</div>
<a rel="nofollow" href="/xiazai/skill10796" title="MySQL8 CRM Schema Design Expert" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 确保
SRID统一为4326（WGS84），否则ST_*()函数行为未定义，索引失效 - 不要在
POINT字段上同时建B-Tree和SPATIAL索引，MySQL 不支持混合索引优化，还拖慢写入 - 批量导入后务必执行
ANALYZE TABLE poi，让优化器知道空间数据分布，否则可能误判索引有效性 - 如果单次查询平均返回 > 1000 行，R-Tree 的 I/O 收益可能被节点遍历开销抵消，此时用
lat/lng双 B-Tree + 范围条件（BETWEEN）更稳
替代方案：不用 R-Tree，靠 B-Tree 也能做高效附近查询？
可以，而且更可控。典型做法是预计算“GeoHash”或“Geohash 前缀”，存成字符串字段并建普通 B-Tree 索引。查附近时，先算出目标点的几个邻近 GeoHash 前缀（如 6 位变 5 位再枚举 8 个方向），然后 IN 查询 + 二次距离过滤。
- 优势：B-Tree 稳定、可预测、支持
Covering Index，适合读多写少、QPS 高的场景 - 注意：GeoHash 精度和前缀长度强相关，6 位约 1.2km，7 位约 150m；选太短漏点，太长索引膨胀
- 别用
MD5(lat,lng)或自定义哈希——它们不保序，无法利用 B-Tree 范围扫描 - 如果业务允许误差 ±500m，且 95% 查询半径 ≤ 3km，GeoHash 方案通常比 R-Tree 更快、更易监控
真正难的不是选 R-Tree 还是 GeoHash，而是确认你的数据分布、QPS 模式和延迟 SLA。线上跑着的查询，EXPLAIN 里看到 type: spatial 不代表快，得看 rows 和 filtered —— 很多时候那个 “spatial” 只是骗过了眼睛。
