千万级地理位置数据必须用innodb，因myisam不支持事务、行级锁、空间函数（如st_distance_sphere）、崩溃自动恢复，且空间索引在高并发下易失效或报错。
千万级地理位置数据必须用 InnoDB，MyISAM 不可选。
MySQL 8.0 已全面废弃 MyISAM 的核心支持，系统表全部迁移至 InnoDB；而地理位置场景天然需要事务、并发写入、空间索引一致性与崩溃恢复能力——MyISAM 在这几点上全不满足。
地理查询依赖 ST_* 函数和空间索引，InnoDB 才支持
MySQL 的空间类型（POINT、POLYGON）和空间函数（如 ST_Distance_Sphere、ST_Contains、ST_Intersects）从 MySQL 5.7 起要求存储引擎必须支持事务和聚簇索引，只有 InnoDB 满足条件。
MyISAM 虽然能建 SPATIAL 索引，但：
- 不支持 ST_Distance_Sphere（会报错 Function 'st_distance_sphere' is not supported by storage engine）
- 空间索引无法与 WHERE 条件组合优化，执行计划常退化为全表扫描
- 无 MVCC，多线程并发更新坐标时极易覆盖或丢失数据
高并发写入下 MyISAM 表锁直接卡死服务
地理位置数据常见于轨迹上报、POI 实时更新、围栏触发等场景，写入频次高且需低延迟： -INSERT INTO location_log (device_id, pos, ts) VALUES (...) 在 MyISAM 中会锁整个表，QPS 上百就排队
- 同一设备多次位置更新（如每秒 5 条 GPS 点）在 MyISAM 下实际串行执行，延迟累积
- InnoDB 的行级锁 + INSERT ... ON DUPLICATE KEY UPDATE 可安全处理重复设备上报
列表对比关键行为：
-
UPDATE location SET pos = POINT(116.3,39.9) WHERE device_id = 'd123'：MyISAM 锁全表；InnoDB 仅锁匹配行 DELETE FROM location_log WHERE ts ：MyISAM 删除期间所有写入阻塞；InnoDB 可并发插入新点- 崩溃后恢复：MyISAM 需手动
REPAIR TABLE，且可能丢点；InnoDB 自动回放 redo log，保证轨迹连续性
空间索引性能差异远不止“快慢”，而是“能否用”
即使只读场景，MyISAM 的空间索引也存在硬伤： - 它的SPATIAL 索引基于 R-Tree，但不维护 MVCC 版本，导致 SELECT ... WHERE ST_Within(pos, GEOMFROMTEXT('POLYGON((...))')) 在并发查询时可能返回部分更新中的脏状态
- InnoDB 的空间索引与 Buffer Pool 集成，支持预读和页内压缩，对千万级点集的范围查询（如“查某城市内所有车辆”）响应更稳
- 实测：1200 万点数据，相同 ST_Contains 查询，InnoDB 平均 82ms（命中空间索引），MyISAM 1.4s（索引失效，全表扫描）
真正容易被忽略的是——ALTER TABLE ... ADD SPATIAL INDEX 在 MyISAM 上看似成功，但后续任何涉及空间计算的 DML 都可能触发隐式表锁或索引损坏，而错误日志里往往只记 Got error 139 from storage engine，排查成本极高。
别被“MyISAM 读快”误导：地理位置业务从来不是纯读，而是读写混合、强一致性要求、不可接受数据丢失的场景。选 MyISAM 就等于主动放弃事务、并发、恢复、空间函数四大支柱。
