InnoDB截至2026年4月所有稳定版均不支持SPATIAL索引，建索引会报ERROR 1478；MyISAM虽支持但仅基于MBR，空间函数非精确计算；InnoDB用户需用DECIMAL/JSON+ST函数等替代方案，但均有性能或功能缺陷。
MyISAM 支持 SPATIAL 索引，InnoDB 在 2026 年 4 月前所有稳定版都不支持
直接结论：如果你在 InnoDB 表上执行 CREATE SPATIAL INDEX 或对 POINT/POLYGON 列加空间索引，MySQL 会立刻报错：ERROR 1478 (HY000): Table storage engine 'InnoDB' does not support SPATIAL indexes。这不是配置问题，也不是版本太低——这是引擎层面的硬性限制，截至 2026 年 4 月，所有已发布的 InnoDB 稳定版本（包括 MySQL 8.0.x、8.1.x、8.2.x）均未实现 SPATIAL 索引支持。
MyISAM 的 SPATIAL 索引仅基于 MBR，不支持精确几何计算
MyISAM 虽然能建 SPATIAL 索引，但底层只维护最小边界矩形（MBR），所有空间函数如 ST_Contains()、MBRWithin() 实际走的是矩形包围盒判断，不是真实几何拓扑关系。这意味着：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 两个多边形仅在 MBR 相交但几何上无重叠时，
ST_Contains()可能返回TRUE -
ST_Distance()返回的是 MBR 中心点距离，不是实际欧氏或球面距离 - 无法做曲面距离、环形缓冲区（buffer）、拓扑有效性校验等操作
- 即使字段是
POLYGON类型，也无法用ST_IsValid()做可靠验证
InnoDB 用户想存坐标，常见替代方案及坑点
若业务强制使用 InnoDB（如需事务、外键、行锁），又必须处理地理数据，主流做法有三种，但各自有明显局限：
- 用两个
DECIMAL(10,8)字段存lat和lng，加普通B-tree索引，配合WHERE lat BETWEEN ? AND ? AND lng BETWEEN ? AND ?做粗略范围筛选——但无法表达圆形、多边形围栏，且高纬度地区经纬度“度=距离”偏差极大 - 用
JSON字段存 WKT（如{"type":"Point","coordinates":[116.4,39.9]}），再用ST_Distance_Sphere()计算——该函数在 MySQL 8.0.25+ 可运行，但 不走索引，每次都是全表扫描，10 万行以上性能断崖下跌 - 升级到 MySQL 8.0.25+ 后启用
ST_*()函数（如ST_Contains()、ST_Within()）——函数可用，但因底层无空间索引支撑，查询仍为 O(n) 复杂度，和没索引一样慢
建表时 ENGINE=MyISAM 是唯一决定性操作
空间索引能力完全由表的存储引擎决定，跟全局配置、sql_mode、innodb_file_per_table 等无关。哪怕你导出一个带 SPATIAL 索引的 MyISAM 表再导入，只要建表语句漏写 ENGINE=MyISAM，MySQL 5.7+ 默认会用 InnoDB，结果就是空间列能建，索引建不上，后续所有空间函数调用都会失败或退化为全表扫描。真正需要高性能 GIS 查询时，别硬扛——把空间数据拆出去，交给 PostGIS 或专用地理服务更现实。
