必须用空间索引+ST_DWithin预过滤，否则全表扫描致性能崩溃；ST_Distance_Sphere在JOIN中不走索引，需先圈候选集再精算距离。
直接说结论：不用 ST_Distance_Sphere 在 JOIN ON 里暴力算距离，必须用空间索引 + ST_WithinDistance 或 ST_Intersects 配合预过滤，否则 10 万级点对点匹配会卡死。
MySQL 中 Spatial Join 为什么不能直接写 WHERE ST_Distance_Sphere(a.loc, b.loc) < 5000
因为 MySQL 在 UPDATE 或复杂 JOIN 中不支持在 ON 条件里调用空间函数做实时距离计算，更关键的是——它根本不会走空间索引。即使你建了 SPATIAL INDEX，只要写成 WHERE ST_Distance_Sphere(...) < N，优化器就自动退化为全表扫描 + 逐行计算，CPU 拉满，5 秒变 5 分钟。
真正起效的方式是把“距离判断”拆成两步：
- 先用空间索引快速圈出「可能相邻」的候选集（比如用
ST_Contains或ST_DWithin的等效替代） - 再在小结果集上精确算距离（可选）
MySQL 8.0.29+ 支持 ST_DWithin（需 SRID=4326），但注意：它底层仍依赖空间索引是否命中；若没建索引或字段类型不对（比如用了 POINT 却没设 SRID），函数直接返回 NULL。
建空间索引前必须确认的三件事
空间索引不是建了就生效，漏掉任一条件都会让查询回到全表扫描：
-
location字段必须是POINT类型，且显式声明SRID 4326：ALTER TABLE users MODIFY location POINT SRID 4326; - 插入数据必须用
ST_GeomFromText('POINT(116.403963 39.915119)', 4326)，不能只写坐标字符串或用POINT()构造函数（后者不带 SRID） - 索引必须用
SPATIAL关键字创建：CREATE SPATIAL INDEX idx_location ON users(location);，普通INDEX对空间函数无效
常见错误现象：EXPLAIN 显示 type: ALL、key: NULL，哪怕 SQL 里写了 ST_WithinDistance —— 八成是上面三点中某一条没满足。
批量更新地理位置时如何避免 UPDATE 不支持子查询别名
MySQL 不允许在 UPDATE ... JOIN 中直接引用子查询的别名（比如 (SELECT ... FROM places) p），而你又需要先对每个用户找最近的 POI，这就得绕开语法限制：
- 用
UPDATE ... JOIN (SELECT ...)形式，把距离计算逻辑塞进子查询里，且必须加WHERE ST_DWithin(u.location, p.location, 5000)做初筛 - 子查询里要包含
GROUP BY u.id或ROW_NUMBER() OVER(...)（但 MySQL 8.0 才支持窗口函数，且UPDATE仍不认）→ 实际只能靠ORDER BY ST_Distance_Sphere(...) LIMIT 1配合JOIN模拟 - 更稳的做法：先用临时表存匹配结果：
CREATE TEMPORARY TABLE tmp_match AS SELECT u.id, p.id AS poi_id, ST_Distance_Sphere(u.location, p.location) d FROM users u JOIN places p ON ST_DWithin(u.location, p.location, 5000) WHERE ... ORDER BY d;，再用这个表去UPDATE users
性能影响明显：加 ST_DWithin 过滤后，JOIN 行数从百万级降到几千，临时表构建时间通常
Trino 和 MySQL 空间索引行为的关键差异
如果你在对比 Trino 和 MySQL 的地理关联性能，别直接套用同一套写法——它们的空间索引机制完全不同：
- Trino 默认启用
use-spatial-index-for-spatial-join，底层用 STRtree，对JOIN ... ON ST_Intersects(a.geom, b.geom)自动加速，无需手动加WHERE过滤 - MySQL 完全依赖你显式写出
ST_DWithin或ST_Contains，且必须确保左右操作数都命中空间索引；ST_Intersects在 MySQL 中对点-点关系意义不大（永远返回 true 或 false，不利用索引） - Trino 的空间索引是分布式的，适合跨节点大表；MySQL 的空间索引是单机 B+ 树变体，数据量超 500 万行后效果衰减明显，此时应考虑分表或导出到 PostGIS
最容易被忽略的一点：MySQL 的 ST_DWithin 第三个参数单位是「米」，但仅当 SRID=4326 时才准确；如果误用 SRID=0 或其他坐标系，数值会严重失真，导致该命中的没命中，不该命中的全扫进来。
