MyISAM支持SPATIAL索引而InnoDB不支持（截至2026年4月），因InnoDB执行CREATE SPATIAL INDEX会报错ERROR 1478；MyISAM用R-Tree实现MBR级空间过滤，适用于地理围栏粗筛但存在假阳性，且不支持精确几何计算与球面距离索引加速。
MyISAM 支持 SPATIAL 索引而 InnoDB 不支持（截至 2026 年 4 月）
直接原因就一条：CREATE SPATIAL INDEX 在 InnoDB 表上会报错：ERROR 1478 (HY000): Table storage engine 'InnoDB' does not support SPATIAL indexes。MyISAM 是 MySQL 唯一原生支持空间索引的稳定版存储引擎——它用 R-Tree 实现 SPATIAL 索引，能加速 MBRContains()、MBRWithin()、ST_Contains() 这类查询。
注意：虽然 MySQL 5.7.4 起 InnoDB 允许定义 POINT、POLYGON 等列类型，但只是“能存”，不等于“能索引”。没有索引支撑的空间查询，在 InnoDB 上就是全表扫描。
MyISAM 的 R-Tree 索引对地理围栏类查询有效，但有精度限制
MyISAM 的空间索引基于最小边界矩形（MBR），不是精确几何计算。这意味着：
-
ST_Contains(g1, g2)在 MyISAM 上实际走的是 MBR 层级的快速过滤，可能返回“假阳性”（比如一个细长多边形被 MBR 包含，但实际几何不包含） - 它不支持曲面距离（如地球球面距离）、拓扑关系验证或
ST_Distance_Sphere()这类函数的索引加速 - 如果你只做「点是否在某区域 MBR 内」这类粗筛，性能很好；但要做「用户是否真在商圈多边形内」，必须加二次 SQL 过滤或应用层校验
MyISAM 空间功能和全文索引是两套独立机制
别指望 FULLTEXT 索引能帮你搜“朝阳区三里屯附近的咖啡馆”——MyISAM 的全文索引不支持中文分词，也和空间列完全无关。你无法用一个 MATCH ... AGAINST 同时匹配地址文本 + 地理位置。
常见错误做法是把坐标和描述都塞进一个 TEXT 字段，再建 FULLTEXT，结果查不到任何空间关系。正确拆法是：
- 用
POINT列 +SPATIAL索引做地理范围初筛 - 另起一个
TEXT字段 +FULLTEXT索引（或外接 Elasticsearch）做关键词检索 - 最后用
AND连接两个条件，或在应用层取交集
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_*()函数无法走索引，小数据量还行，超过万级就明显卡顿 - 升级到 MySQL 8.0.25+，用
ST_Distance_Sphere()算距离，但底层仍是全表扫描 —— 官方文档明确写清：“no spatial index support on InnoDB”，别信“能用函数=能加速”的误解
真正需要高性能地理查询的场景，比如实时轨迹匹配、LBS 推荐、电子围栏告警，MyISAM 的 R-Tree 至今仍是 MySQL 生态里最轻量可用的方案——前提是，你能接受它不支持事务、只支持表锁、且修复损坏表可能丢数据这个事实。
