mysql 5.6及更早版本的空间索引仅支持myisam引擎，因innodb缺乏srid、mbr元数据支持及事务安全的r-tree实现；8.0通过专用空间页格式、强制srid、事务安全索引重建等实现稳定支持。
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 新增了专用的空间页格式（
SPATIALpage 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 统一、索引重建、函数语义校准，三者缺一不可。漏掉任何一项，空间查询性能都会断崖下跌，而错误往往藏在慢日志里，不会抛异常。
