MyISAM更适合存储地理空间数据类型，因其原生支持SPATIAL索引（基于R-Tree实现MBR过滤），而InnoDB在2026年4月前所有稳定版均不支持，执行CREATE SPATIAL INDEX会直接报错ERROR 1478。
MySQL 5.6 及更早版本中 SPATIAL 索引报错 ERROR 1478
直接原因是 InnoDB 引擎在 5.6 之前压根没实现空间索引的底层支撑，不是配置问题，也不是语法写错。你执行 CREATE SPATIAL INDEX 或在 POINT 列上加空间索引时，MySQL 会立刻拒绝并抛出：ERROR 1478 (HY000): Table storage engine 'InnoDB' does not support SPATIAL indexes。这不是警告，是硬性拦截——解析器在语义检查阶段就终止了。
MyISAM 的 R-Tree 实现为什么能“跑起来”
MyISAM 的空间索引基于轻量级、无事务依赖的 R-Tree，索引条目直接映射几何对象的 MBR（最小边界矩形），结构扁平，不涉及行格式、MVCC 版本链或崩溃恢复逻辑。它把索引和数据文件（.MYI 和 .MYD）完全解耦，建索引就是顺序写入固定格式的二进制块，天然适合静态 GIS 场景。
- 支持
MBRContains()、MBRWithin()这类仅靠矩形包围盒就能快速判断的函数 - 不校验 SRID，
ST_SRID(col)返回 0 也照常建索引 -
NULL值可参与索引构建，无需显式约束
InnoDB 在 5.6 缺失的关键能力
InnoDB 当时的聚簇索引架构和行存储格式（如 COMPACT）无法安全承载空间数据的元信息与操作语义：
- 没有原生 SRID 存储字段，几何列本质是二进制 blob，无法表达坐标系含义
- 缺乏 MBR 元数据缓存与快速提取机制，每次计算都需反序列化完整 WKB
- R-Tree 分裂/合并过程无法与事务日志（redo log）对齐，破坏 ACID
- 没有专用的空间页类型，强行复用 B+Tree 页面会导致 MBR 比较逻辑失效
换句话说，不是“懒得加”，而是加了就会让事务、崩溃恢复、并发控制全部失守。
升级到 MySQL 8.0 后仍查不到空间索引效果？
即使你把老 MyISAM 表转成 InnoDB，再执行 ALTER TABLE t ADD SPATIAL INDEX，查询依然可能退化为全表扫描——EXPLAIN 显示 type: ALL，key: NULL。常见原因有：
- 几何列未声明 SRID：
ALTER TABLE t MODIFY geom_col POINT SRID 4326 NOT NULL必须先做 - 旧索引残留：MyISAM 的
.MYIR-Tree 文件不会被自动迁移，必须手动DROP INDEX再重建 - 函数误用：
ST_Distance(g1, g2)在 8.0 + SRID 4326 下默认返回球面距离（米），而 5.6 MyISAM 返回的是笛卡尔平面距离，数值差几个数量级，容易误判“结果不准=没走索引”
最隐蔽的坑是行为漂移而非语法错误：索引建成功了，但业务 SQL 因函数语义变化实际没受益，连 EXPLAIN 都看不出问题。
