mysql 8.0 必须使用 innodb 存储地理空间数据，因其唯一支持事务、mvcc、空间索引与 st_* 函数一致性读；myisam 缺乏事务安全与空间操作一致性保障。
MySQL 8.0 推荐用 InnoDB 存储地理空间数据，不是因为“它支持”，而是因为只有 InnoDB 能在事务、并发和一致性前提下，正确支撑地理空间操作——MyISAM 等引擎要么不支持空间索引的事务安全，要么根本无法保证 ST_* 函数执行期间的数据状态一致。
ST_Geometry 类型必须搭配事务引擎
MySQL 8.0 中所有 GEOMETRY、POINT、POLYGON 等空间类型字段，若参与 INSERT / UPDATE / DELETE，就必须运行在支持事务的引擎上。否则会出现：
-
ERROR 1406: Data too long for column 'geom' at row 1（实际是隐式回滚失败导致校验异常） -
ST_Contains或ST_Intersects查询结果在并发写入时出现“瞬时不一致”——比如刚插入一个面，另一事务立刻查却查不到，或查到破损几何 - 空间索引（
R-tree）更新与数据行更新不同步，ANALYZE TABLE后仍报Invalid GIS data provided to function st_contains
而 InnoDB 是 MySQL 8.0 唯一同时满足：支持空间类型 + 支持空间索引 + 支持事务 + 支持 MVCC 下空间函数一致性读 的引擎。
空间索引在 InnoDB 中才真正生效
MyISAM 虽然也支持 SPATIAL 索引，但它是表级锁 + 无事务 + 不支持 ST_* 函数的隔离性语义。在 MySQL 8.0 中，InnoDB 的空间索引基于改进的 R-tree 实现，并与缓冲池、redo log 深度集成：
- 创建空间索引必须用
SPATIAL KEY，且仅在InnoDB表中能触发真正的R-tree构建（MyISAM实际走的是降维 B-tree 模拟） -
ST_DistanceSphere等计算类函数，在InnoDB下可利用空间索引做快速范围预剪枝；MyISAM则常退化为全表扫描 + 内存计算 -
ALTER TABLE ... ADD SPATIAL INDEX在InnoDB中是在线操作（ALGORITHM=INPLACE），而MyISAM必须锁表重建
崩溃后空间数据不会损坏
地理空间数据一旦写入破损（如 POLYGON 环未闭合、坐标溢出），ST_IsValid(geom) 会返回 0，后续几乎所有空间函数都失效。而 InnoDB 的双重保障机制能避免这类问题：
- 写入前通过
innodb_strict_mode=ON（默认开启）校验几何有效性，无效值直接拒绝插入，不写入磁盘 - 崩溃时，
redo log重放会完整恢复空间索引页结构，不像MyISAM那样依赖myisamchk手动修复，且修复后无法保证 R-tree 一致性 -
ST_Buffer、ST_Union等复杂操作在事务中执行，中途失败自动回滚，不会留下半成品几何对象
真正容易被忽略的点：即使你只读查询地理数据，只要表里存在并发写入（比如后台定时任务更新 POI 坐标），就一定要用 InnoDB ——否则 ST_Within 返回的结果可能对应已删除或未提交的中间状态，而这种不一致在日志里几乎不报错，只表现为业务逻辑偶发失败。
