MySQL多维地理数据为何需要空间索引？

许多开发者在使用MySQL处理地理数据时，容易踩到一个常见的坑：普通B-tree索引对POINT字段完全无效。原因在于，MySQL的POINT字段底层采用WKB（Well-Known Binary）二进制格式，而B-tree索引依赖的是字典序比较。问题在于，经纬度坐标的二进制表示在字典序上并不具备空间意义——两个地理上相邻的点，其WKB值可能相差悬殊。即使为location字段添加了INDEX(location)，执行EXPLAIN后依然显示type: ALL，即全表扫描。这并非Bug，而是底层数据结构决定的固有特性。

ST_*系列函数依赖SPATIAL INDEX，并非可选项

当使用ST_Contains、ST_Distance_Sphere等空间查询函数时，如果没有SPATIAL INDEX，查询会退化为逐行计算，代价极高：

• ST_Contains()需要遍历每条记录，解析几何对象后执行包含判断；
• ST_Distance_Sphere()需对每条记录计算一次球面距离，再排序取TOP N；
• 即使是查询“5公里内商户”，10万条数据也意味着10万次浮点运算加全表I/O——性能堪忧。

R-tree空间索引则完全不同：它将地理空间划分为嵌套的矩形块，查询时直接剪枝掉明显不重叠的区域，扫描量从O(n)降至接近O(log n)，这才是真正的加速引擎。

创建SPATIAL INDEX的三个硬性前提

常见的失败原因并非语法错误，而是遗漏了某些约束：

• 字段类型必须是空间类型（如POINT、POLYGON），不能是TEXT或JSON存储的坐标字符串；
• 字段必须声明为NOT NULL——MySQL强制要求，否则CREATE SPATIAL INDEX会直接报错；
• 存储引擎必须支持：MyISAM原生支持；InnoDB从5.7起支持，但要求MySQL版本≥5.7.5且innodb_large_prefix=ON。

正确写法示例：CREATE TABLE shops (id INT, loc POINT NOT NULL, SPATIAL INDEX(loc)) ENGINE=InnoDB;

MBRContains快但粗糙，需警惕精度陷阱

如果只需要粗略筛选，例如地图瓦片加载或POI初步过滤，MBRContains()比ST_Contains()快一个数量级。原因很简单：它只比较最小包围矩形（Minimum Bounding Rectangle），不校验真实几何边界。

但这也意味着：

• 多边形凹陷区域内的点可能被遗漏；
• 细长L形区域会被包进一个很大的矩形，导致大量误匹配；
• 务必搭配ST_Contains()做二次精筛——尤其在业务逻辑要求精确包含时，这一步不能省略。

还有一个容易被忽视的点：空间索引本身并不解决投影问题。所有坐标必须统一使用WGS84（EPSG:4326）存入，否则ST_Distance_Sphere()返回的距离会严重失真。这一点，不少DBA都是在上线后才踩坑的。