MySQL 空间索引支持地理范围筛选的设计

MySQL 用空间索引支持地理范围筛选，需要把三件事一起设计：空间列明确限制 SRID，写入和查询使用一致的坐标约定，WHERE 中使用合适的空间关系谓词。只创建 SPATIAL INDEX，再对经纬度表达式做任意比较，并不能据此认定查询会使用它。

本文以 MySQL 8.4、InnoDB 和 SRID 4326 的点位数据为例。官方文档入口：https://dev.mysql.com/doc/refman/8.4/en/。文中数据、表名和区域均为原创教学示例，未连接数据库执行，也没有性能测试或线上执行计划。

先区分空间索引与最终范围条件

MySQL 8.4 的一个重要能力边界是：优化器根据列的 SRID 属性选择适合空间参考系统的包围盒计算。地理坐标不能不加区分地当作平面坐标处理，旧版本的经验也不能原样作为当前版本的保证。

索引解决的是“哪些对象可能满足范围关系”，最终条件解决的是“业务到底怎样算在范围内”。两者有关，却不能互相代替。最小包围矩形 MBR 可以覆盖形状以外的区域；对不规则多边形，矩形相交不代表实际几何形状相交。

因此，设计时先写出业务语义：要查矩形视窗内的点，还是任意服务区内的点？落在边界上的点算不算？这里选择点与指定多边形相交，包含边界相交情况，不讨论最近邻排序、距离单位或按半径生成范围。

让空间列明确约束 SRID 与空值

对点位使用 POINT 比宽泛的 GEOMETRY 更能表达数据契约。NOT NULL 是空间索引建列要求之一；显式 SRID 则约束列中使用的空间参考系统。官方文档说明，没有 SRID 属性的空间列即使维护了空间索引，优化器也不会将其用于这里的空间索引优化。

-- 在独立测试库创建示例表，不要直接覆盖现有业务表。
CREATE TABLE place_scope_demo (
    id BIGINT UNSIGNED NOT NULL PRIMARY KEY,
    label VARCHAR(64) NOT NULL,
    location POINT NOT NULL SRID 4326,
    SPATIAL INDEX sx_location (location)
) ENGINE=InnoDB;

-- 所有输入都明确约定为“经度在前、纬度在后”。
INSERT INTO place_scope_demo (id, label, location) VALUES
(101, '范围内示例', ST_GeomFromText('POINT(116.40 39.90)', 4326, 'axis-order=long-lat')),
(102, '远处示例', ST_GeomFromText('POINT(117.20 40.50)', 4326, 'axis-order=long-lat')),
(103, '顶点示例', ST_GeomFromText('POINT(116.30 39.80)', 4326, 'axis-order=long-lat'));

需要核对的不是“索引名字存在”这一件事，而是完整组合：location 的类型是 POINT，不能为 NULL，列定义带 SRID 4326，并有 SPATIAL 索引。坐标未知的业务记录，不应为了满足 NOT NULL 随意写成零点；可以用业务状态或独立表表达未定位状态。

固定经纬度输入顺序，再构造查询区域

4326 并不意味着 WKT 文本天然按接口常见的“经度、纬度”读取。默认轴顺序由空间参考系统定义。为了让接口传入的经度在前，示例在每次 WKT 构造中都显式使用 axis-order=long-lat，查询区域也遵守同一约定。

如果点位写入采用一个顺序，多边形输入采用另一个顺序，查询可能报经纬度越界，也可能在坐标仍合法时悄悄落到错误位置。后者更难发现，所以检查不能只停留在“构造函数没有报错”。应使用业务上能辨认的位置做读回对照。

SRID 一致也不等于来源坐标天然一致。外部数据采用什么坐标基准、经纬度顺序与单位，应先在导入契约中明确，再进入该列。不要把给数字附上 4326 标签当成已经完成了来源坐标处理。

用 MBR 谓词选候选，再按形状判断

下列查询把 MBRIntersects 放在候选关系中，同时使用 ST_Intersects 判断真实对象形状。这里的“先候选、再判断”是逻辑分工，不是对 SQL 优化器求值顺序的承诺。两个参数都使用 4326，且没有把被索引列转换成字符串或拆成经纬度算式。

-- 多边形首尾坐标闭合，和空间列使用相同SRID及输入轴顺序。
SET @region = ST_GeomFromText(
    'POLYGON((116.30 39.80,116.50 39.80,116.50 40.00,116.30 40.00,116.30 39.80))',
    4326,
    'axis-order=long-lat'
);

-- MBR条件表达候选范围，精确关系决定最终命中；边界点也算相交。
SELECT id, label
FROM place_scope_demo
WHERE MBRIntersects(location, @region)
  AND ST_Intersects(location, @region)
ORDER BY id;

-- 只查看计划，不假定优化器一定选择空间索引。
EXPLAIN
SELECT id
FROM place_scope_demo
WHERE MBRIntersects(location, @region)
  AND ST_Intersects(location, @region);

按示例几何意图，101 是区域内部点，102 位于远处，103 与区域顶点重合；读者应在自己的 MySQL 8.4 环境观察结果。这不是本文实际取得的查询输出。采用地理 SRS 时，多边形边界按该系统的几何语义处理，不应把这段 WKT 笼统称为所有地图投影下完全一致的经纬度屏幕矩形。

当业务仅需要包围矩形关系时，可以把它直接作为最终条件；当业务要求不规则服务区内的点，就需要保留真实形状判断。不能为减少一次函数调用，把所有多边形都偷偷改成外接矩形。

EXPLAIN 用来观察优化器的选择，而不是给索引“盖章”。小表或大范围条件可能使扫描更合适；有可用索引并不强制每次采用。应结合真实数据分布和实际查询范围解释，不要用三条示例记录宣称降低了多少扫描量。

旧表迁移与读者复现需要核对什么

已有空间列的迁移，应先确认实际数据的类型、空值情况及 SRID 分布，再设计统一的数据契约。MySQL 8.4 官方建议对未限制 SRID 的空间列核对现有 SRID，调整为明确约束并重建空间索引；这类变更应在副本或测试环境评估，而不是直接对生产表试错。

-- 在迁移前统计实际存储的SRID，不能只看应用配置。
SELECT ST_SRID(location) AS srid, COUNT(*) AS rows_in_group
FROM place_scope_demo
GROUP BY ST_SRID(location);

-- 读取真实表定义，核对NOT NULL、SRID约束及SPATIAL索引。
SHOW CREATE TABLE place_scope_demo;

-- 用同一输入检查两个谓词，观察候选范围与最终关系是否不同。
SELECT id,
       MBRIntersects(location, @region) AS mbr_hit,
       ST_Intersects(location, @region) AS shape_hit
FROM place_scope_demo
ORDER BY id;

这三组语句分别回答存储值、列定义和谓词关系问题。它们不能相互替代，也不能把“SRID 都是 4326”当成坐标输入绝无错误的证明。应用层构造参数、旧数据来源和目标范围仍需有明确约定。

只对 longitude、latitude 做 BETWEEN，会自动利用空间索引吗？不要这样假定。普通数值列或从几何值提取坐标的表达式，与直接针对空间列的可优化谓词不是同一个访问条件。

空间索引建好了，为什么还看到扫描？先区分列是否满足 SRID 约束、谓词是否适合，再看成本选择。扫描并不自动意味着数据库配置出错。

可不可以只保留 MBR 条件？可以，但前提是最终业务定义就是包围矩形关系。若要求真实服务区形状，必须保留相应精确关系判断。

参考：MySQL 8.4 空间索引与 SRID 限制；空间索引创建要求；WKT 构造与轴顺序；MBR 关系函数；真实形状关系函数。