空间索引 怎样配合 GeoJSON 查询

空间索引配合 GeoJSON 查询的关键，不是给 JSON 文本建立普通索引，而是把 GeoJSON 转成带统一 SRID 的空间值，保存到可建立 SPATIAL INDEX 的 GEOMETRY 列。查询时先用 MBR 条件缩小候选，再用精确空间关系函数判断真实几何关系。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

可以把这套方案看成两个边界：GeoJSON 负责表达输入，空间列和空间索引负责组织候选；MBR 条件负责快速排除，ST_Within 或 ST_Contains 负责最后的几何语义。

本文先记住三点：空间索引建在空间列上；索引使用的是几何的最小外接矩形；MBR 相交只是候选条件，不能直接当成精确包含。

先划清 GeoJSON、几何值与索引的职责

GeoJSON 是一种交换格式，适合从接口或文件传入点、线、面等几何。MySQL 的 ST_GeomFromGeoJSON() 才是把字符串解析为空间值的入口；如果没有显式传入 SRID，函数返回的几何值默认使用 4326。空间索引并不读取 JSON 中的业务属性，也不替代属性筛选。

MySQL 8.4 文档说明，SPATIAL 索引使用 R-tree，并以几何对象的 MBR 建立索引。一个弯曲的多边形、一个点和一个矩形都会先被看成包住它的矩形边界，所以索引天然适合先找“可能相交”的候选。

建立可被空间索引使用的列

表结构应把几何数据放到空间列，并明确 SRID。空间索引列需要 NOT NULL；把几何值留在普通 JSON 列里，后续只能先解析，无法让这列直接承担空间索引职责。

CREATE TABLE place (
    id BIGINT PRIMARY KEY,
    name VARCHAR(120) NOT NULL,
    geom GEOMETRY NOT NULL SRID 4326,
    SPATIAL INDEX idx_place_geom (geom)
); -- 中文注释：空间索引绑定 geom，SRID 统一为经纬度坐标 4326。

写入时把 GeoJSON 转成同一 SRID 的空间值。下面的 options=1 表示遇到高于二维的坐标维度就拒绝；这比静默丢弃高度更容易发现输入契约问题。

SET @point_json = '{"type":"Point","coordinates":[116.397,39.908]}';

INSERT INTO place (id, name, geom)
VALUES (
    1,
    '示例地点',
    ST_GeomFromGeoJSON(@point_json, 1, 4326) -- 中文注释：解析 GeoJSON，并显式约束 SRID。
);

如果输入包含错误的经纬度范围、无法识别的 SRID 或不符合 GeoJSON 结构，转换函数会报错。先把输入转换成空间值，再由空间列的 SRID 契约约束后续查询，边界会比“每次查询临时解析 JSON”清楚。

把查询 GeoJSON 转成同一 SRID 的区域

查询区域也要转换成几何值，并与被查询列保持同一 SRID。以一个矩形区域为例，查询参数可以来自接口的 GeoJSON 字符串；文章中的 SQL 只展示结构，不把示例结果当成已经执行过的输出。

SET @region_json = '{
  "type": "Polygon",
  "coordinates": [[[116.35,39.88],[116.45,39.88],[116.45,39.95],[116.35,39.95],[116.35,39.88]]]
}';

SET @region = ST_GeomFromGeoJSON(@region_json, 1, 4326); -- 中文注释：查询区域与 geom 采用同一个 SRID。

不要把 Feature 的业务属性误当成空间列内容；本篇只讨论 geometry 查询。GeoJSON 的 type 值区分大小写，坐标维度、坐标范围和 CRS 也会影响解析是否成功。

用 MBR 候选加精确关系完成查询

查询的设计要把“快”和“准”拆开。MBRIntersects 适合作为候选条件，让优化器有机会使用空间索引；但两个 MBR 相交，不代表真实几何一定相交或包含。对点落在区域内的任务，可以在候选之后再用 ST_Within 做精确判断。

SELECT id, name
FROM place
WHERE MBRIntersects(geom, @region) -- 中文注释：先按 MBR 找可能落入区域的候选。
  AND ST_Within(geom, @region);    -- 中文注释：再按真实几何关系过滤，避免只相信外接矩形。

如果业务语义是“区域包含对象”，也可以把精确关系写成 ST_Contains(@region, geom)。函数方向不能随意交换：ST_Within(a,b) 表示 a 在 b 内，ST_Contains(a,b) 表示 a 包含 b。MBR 条件只是索引友好的预筛选，不应单独作为最终答案。

四个容易让索引方案失真的边界

这套结构的代价也很明确：空间列会增加写入和索引维护成本，复杂几何的 MBR 可能覆盖较大范围，候选集仍然需要精确函数过滤。不要因为“有索引”就假定所有空间查询都会变快，索引是否适合仍取决于数据分布和查询边界。

按这份清单判断是否配对正确

• GeoJSON 只负责输入或输出，落库字段是空间类型而不是原始 JSON 文本。
• 空间列的 SRID、写入几何和查询几何保持一致。
• 空间索引列声明为 NOT NULL，并使用 SPATIAL INDEX。
• 候选条件与精确关系分开，不能把 MBRIntersects 当成最终业务语义。
• 根据任务选择 ST_Within、ST_Contains 等方向正确的关系函数。

两个容易混淆的问题

GeoJSON 放进 JSON 列后还能用空间索引吗？ 这只能保留原始交换数据，不能替代空间列。需要空间查询时，应将它解析并保存到带 SRID 的空间列，原始 JSON 是否保留是另一个数据留存决定。

MBRIntersects 返回 true 就一定真实相交吗？ 不一定。它比较的是最小外接矩形，复杂形状的 MBR 可能相交而真实几何不相交，所以需要再使用精确空间关系函数。

最终可以把判断压缩成一句话：GeoJSON 进来先转几何，几何列统一 SRID，空间索引负责候选，精确关系负责结论。