MySQL 5.6以下版本中，MyISAM独享空间索引功能，至8.0版InnoDB也支持，为何升级？

本文共计892个文字，预计阅读时间需要4分钟。

MySQL 5.6 及更早版本中，空间索引（SPATIAL）仅支持 MyISAM 引擎。InnoDB 引擎在 5.7 版本开始实验性支持空间索引，而在 8.0 版本中才真正稳定可用。这不是设计上的疏漏，而是底层实现机制决定的。

为什么5.6的InnoDB不支持SPATIAL索引

MyISAM 的空间索引基于 R-Tree 实现，且其索引结构是“扁平”的：每个几何对象直接映射到一个固定格式的索引条目，不依赖事务或 MVCC。而 InnoDB 在 5.6 时的聚簇索引架构、行格式（如 COMPACT）、以及缺乏对几何类型 SRID 和 MBR（Minimum Bounding Rectangle）的原生元数据支持，导致无法安全地构建和维护空间索引。强行添加会破坏事务一致性，所以 MySQL 官方直接禁用了该功能。

MySQL 8.0 中 InnoDB 空间索引的关键变化

8.0 不是简单“放开限制”，而是重构了空间数据的存储与索引逻辑：

• 所有几何列必须显式声明 SRID（如 POINT SRID 4326），不再允许混合 SRID；
• InnoDB 新增了专用的空间页格式（SPATIAL page type），支持高效 MBR 比较和 R-Tree 分裂/合并；
• 优化器能识别 ST_Within、ST_Distance 等函数并下推到索引层，而 5.6 的 MyISAM 空间索引仅支持 MBRContains 类粗粒度操作；
• 索引本身成为事务安全对象：DROP INDEX 或 ALTER TABLE ... ADD SPATIAL INDEX 是原子操作。

升级后必须重做空间索引

即使你把 5.6 的 MyISAM 表先转成 InnoDB（ALTER TABLE t ENGINE=InnoDB），它的旧空间索引也不会自动生效——因为：

• MyISAM 的 R-Tree 索引文件（.MYI）和 InnoDB 的 B+Tree + 空间页完全不兼容；
• 5.6 表中几何列没有 SRID 属性，ST_SRID(col) 返回 0，而 8.0 要求非零且一致；
• 升级后查询会静默退化为全表扫描，EXPLAIN 显示 type: ALL，无 key 字段。

正确做法是：升级到 8.0 后，先统一列 SRID（ALTER TABLE t MODIFY geom_col POINT SRID 4326 NOT NULL），再删旧索引、重建：ALTER TABLE t DROP INDEX sp_idx; ALTER TABLE t ADD SPATIAL INDEX sp_idx(geom_col);

容易被忽略的兼容陷阱

最隐蔽的问题不是语法报错，而是行为漂移：

• ST_Distance(g1, g2) 在 5.6(MyISAM) 返回笛卡尔距离，8.0(InnoDB+SRID 4326) 默认返回球面距离（单位米），结果可能差几个数量级；
• 5.6 允许 NULL 值参与空间索引，8.0 要求列定义为 NOT NULL 才能建 SPATIAL 索引；
• 如果应用里用 WHERE MBRIntersects(col, ST_GeomFromText('...'))，8.0 下必须确保右侧字面量也带 SRID，否则索引失效。

别只盯着引擎切换——SRID 统一、索引重建、函数语义校准，三者缺一不可。漏掉任何一项，空间查询性能都会断崖下跌，而错误往往藏在慢日志里，不会抛异常。