MySQL 空间索引怎么验证真正生效：SRID 约束、MBRContains 与经纬度范围

空间索引“建好了”不等于查询“用上了”。在 MySQL 8.4 里，先把经纬度列的坐标系固定下来，再用带空间谓词的查询和 EXPLAIN 复核，才能确认优化器确实有机会走 SPATIAL INDEX。下面用一个保存门店位置的 locations 表，把这条验证链跑一遍。

最可靠的判断顺序是：检查 SRID 约束和索引定义，再确认查询使用 MBRContains 或 MBRWithin，最后看 EXPLAIN 是否出现空间索引访问；只看“索引存在”是不够的。

先确认空间列和坐标范围没有混乱

先建立一张最小表。示例把 position 声明为 SRID 4326，数据约定为经度在前、纬度在后。这个约定要在写入代码和查询参数中保持一致。

CREATE TABLE locations (
  id BIGINT PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  position POINT SRID 4326 NOT NULL,
  SPATIAL INDEX idx_locations_position (position)
);

INSERT INTO locations (id, name, position) VALUES
  (1, '浦东门店', ST_SRID(POINT(121.50, 31.23), 4326)),
  (2, '徐汇门店', ST_SRID(POINT(121.44, 31.19), 4326));

先检查定义，而不是急着测查询：

SHOW CREATE TABLE locations;
SELECT id, ST_SRID(position), ST_X(position), ST_Y(position)
FROM locations;

结果至少要满足三点：列的 SRID 是 4326；经度值落在 -180 到 180，纬度值落在 -90 到 90；查询窗口也使用 SRID 4326。若把纬度写到前面，索引可能仍然存在，但返回结果已经不可信。

用 MBRContains 写出可复核的范围查询

构造一个覆盖上海部分区域的矩形。MBRContains 的第一个参数是窗口，第二个参数是表中的空间对象：

SET @window = ST_SRID(
  ST_GeomFromText('POLYGON((121.40 31.15,
                              121.40 31.30,
                              121.60 31.30,
                              121.60 31.15,
                              121.40 31.15))'),
  4326
);

SELECT id, name
FROM locations
WHERE MBRContains(@window, position);

这条语句的查询路径可以拆成：窗口几何体进入 MBRContains，优化器尝试用 SPATIAL INDEX 找候选，再返回命中的 locations 行。MySQL 文档明确说明，优化器会考察 WHERE 中使用 MBRContains() 或 MBRWithin() 的查询是否能使用空间索引。

EXPLAIN 里看什么才算有证据

对同一条查询运行：

EXPLAIN
SELECT id, name
FROM locations
WHERE MBRContains(@window, position);

重点看访问方式和使用的键名，不要只盯着估算行数。若执行计划展示了 idx_locations_position 或空间索引相关访问，说明优化器至少把该索引纳入了候选路径。小表上估算成本可能让计划看起来不明显，这时可以用更多真实数据、同一查询的冷暖缓存对照，以及 EXPLAIN 前后的索引定义共同判断。

还要区分“候选过滤”和“精确几何判断”。MBR 函数依据最小外包矩形；复杂多边形的外包矩形可能包含一些实际不在图形内部的候选点。业务若要求精确边界，先用 MBR 缩小候选，再补充合适的精确空间关系函数，并单独测试边界点。

三类失败现象对应三种修复动作

列没有 SRID 约束

如果不同坐标系的数据都能写进同一列，先清理或隔离旧数据，再把列改成明确 SRID。不要用一个看似正确的索引掩盖坐标系混用。

窗口和列的 SRID 不一致

检查构造窗口的函数调用，以及应用层传入的坐标。窗口的 ST_SRID 和 position 必须符合同一空间参考系；不要只改查询文字而忽略数据写入路径。

查询没有走空间索引

先确认表确实存在 SPATIAL INDEX，再确认谓词使用了 MBRContains 或 MBRWithin。如果把空间列包进无法识别的表达式，或把范围逻辑拆成普通字符串比较，优化器就没有稳定的空间索引入口。

用一组边界数据做反向验证

验证不能只测一个明显命中的点。至少准备窗口内部、窗口外部和落在边界上的对象，分别观察 MBRContains 的返回值；再用 ST_X、ST_Y 检查坐标顺序。对于复杂几何体，把 MBR 候选结果与精确关系函数的结果并列比较，确认误报是否符合业务容忍度。

SELECT
  id,
  ST_SRID(position) AS srid,
  ST_X(position) AS longitude,
  ST_Y(position) AS latitude,
  MBRContains(@window, position) AS in_box
FROM locations;

EXPLAIN SELECT id, name
FROM locations
WHERE MBRContains(@window, position);

最后把这条检查放进迁移或上线验收脚本：表结构、样例坐标、范围谓词和执行计划缺一不可。这样以后重建索引、迁移数据或更换查询窗口时，问题会在验收阶段暴露，而不是等地图结果出现偏移才追查。

常见问题

空间索引存在就一定会被使用吗？

不一定。优化器还要结合谓词形式、数据规模和成本判断；必须针对实际查询检查 EXPLAIN。

MBRContains 和 ST_Contains 是一回事吗？

不是。前者比较最小外包矩形，后者按几何对象形状判断。范围预筛选和精确业务判断要分开测试。

为什么经纬度顺序特别容易出错？

POINT 的两个坐标都是数字，顺序错了通常仍能写入。用 ST_X、ST_Y 和已知位置样本做回读检查，才能尽早发现。

总结

验证 MySQL 空间索引要从数据定义开始：固定 SRID，核对经纬度范围，建立 SPATIAL INDEX，用 MBRContains 写出空间范围查询，再通过 EXPLAIN 观察实际候选路径。对于边界敏感的业务，还要把 MBR 结果和精确几何判断分开验收。