myisam的spatial索引仅支持geometry类型字段（非point等子类型），需not NULL且无默认值，仅mbrcontains/mbrwithin等mbr函数可走r-tree索引，st_contains等精确函数不走索引，不支持order by距离排序，添加或repair后易失效。
MyISAM 的 SPATIAL 索引只支持 POINT、LINESTRING、POLYGON，且必须用 GEOMETRY 类型字段
MyISAM 的空间索引本质是 R-Tree，但它对数据类型和建表方式极其挑剔。不是所有地理字段都能加 SPATIAL 索引——必须是 GEOMETRY 类型（不能是 POINT 单独类型），且该字段不能为 NULL，也不能有默认值。
常见错误现象：Error 1464 (HY000): table storage engine for 't' doesn't support SPATIAL indexes，其实是用了 InnoDB；或 ERROR 1170 (42000): BLOB/TEXT column 'loc' used in key specification without a key Length，说明你误用了 TEXT 或没指定 GEOMETRY 类型。
- 建表时必须显式声明
loc GEOMETRY NOT NULL - 插入前要用
ST_GeomFromText('POINT(116.3 39.9)')而不是直接写字符串 -
ST_PointFromText()是别名，但 MyISAM 实际依赖的是GEOMETRY字段的底层结构，不认子类型别名
查询必须用 MBRContains() 或 MBRWithin() 才走 R-Tree 索引
MyISAM 的空间索引不会被 ST_Contains()、ST_Intersects() 这类精确几何函数触发——它们会退化为全表扫描。真正能利用 R-Tree 的，只有 MBR（Minimum Bounding Rectangle）前缀函数。
使用场景：比如查“某矩形区域内所有门店”，不是“是否严格落在多边形内”。精度要求不高、但速度敏感的粗筛很适合。
- 正确写法：
WHERE MBRContains(ST_GeomFromText('POLYGON((...))'), loc) - 错误写法：
WHERE ST_Contains(...)—— 看似语义更准，但索引失效 -
MBRContains(a,b)要求a是大范围（如查询框），b是单个点/线/面，顺序反了不报错但结果恒为0
MyISAM 空间索引不支持 ORDER BY ... LIMIT 优化，无法高效做“最近 N 个点”
想查“离 (116.3,39.9) 最近的 10 个点”？别指望 ORDER BY ST_Distance(loc, ...) LIMIT 10 能用上空间索引。MyISAM 的 R-Tree 不提供距离排序能力，这个查询必然全表计算距离。
性能影响明显：10 万行数据可能要几百毫秒，且无法通过加索引改善。
- 替代方案只能预计算曼哈顿或经纬度差的边界，先用
MBRContains()圈出候选集，再在应用层或子查询里算精确距离 - 如果业务强依赖邻近搜索，MyISAM 就不该选——换 postgresql + PostGIS，或 mysql 5.7+ 的 InnoDB +
ST_DistanceSphere()（虽仍不走索引，但至少有函数） - 注意：
ST_Distance()在 MyISAM 中返回欧氏平面距离，对经纬度是错的；必须自己转球面公式或用外部库
MyISAM 空间索引无法在线添加，且修复表会丢掉索引元数据
给已有 MyISAM 表加 SPATIAL 索引，必须 ALTER TABLE t ADD SPATIAL INDEX(loc)，但这个操作会锁表、重建整个 .MYI 文件。更麻烦的是：一旦执行过 REPAIR TABLE（比如表损坏后修复），MyISAM 会清空空间索引的内部 R-Tree 结构，导致后续 MBRContains() 全部返回空——但不报错，极难排查。
- 上线前务必用
SHOW INDEX FROM t确认SPATIAL类型存在，且Comment列显示R-tree - 备份策略要包含
.MYI文件，不能只靠mysqldump—— 它不导出索引结构 - 升级 MySQL 版本（尤其是 5.5→5.6）可能触发隐式
REPAIR，老数据表务必提前验证空间查询是否仍有效
MyISAM 的 R-Tree 是个窄通道：只认特定类型、只响应特定函数、不支持常见排序需求，还容易在维护中静默失效。真要用，得把数据形态、查询模式、运维动作全卡死在它认可的范围内。