空间索引和全文索引均不走b+tree路径，而是分别依赖gis引擎的r-tree和全文检索子系统的倒排索引；普通索引则严格遵循b+tree查找逻辑。
空间索引查询走的是GIS专用路径，不走B+Tree遍历
MySQL对SPATIAL索引的查询不依赖标准B+Tree结构，而是调用底层GIS引擎（如MyISAM的R-tree实现或InnoDB 5.7+的增强R-tree）进行几何对象关系判断。比如执行ST_Contains()或MBRIntersects()时，MySQL会把查询转换为最小边界矩形（MBR）相交计算，再逐层过滤真实几何关系。这意味着：WHERE geom_col && POINT(1,1)不会像普通索引那样做“键值比较+回表”，而是直接进入空间划分逻辑。
常见错误现象：在非GEOMETRY类型列上建SPATIAL索引会报错ERROR 1170 (42000): BLOB/TEXT column 'xxx' used in key specification without a key length；或者在InnoDB表中对POINT字段用=等值查询，发现无法命中索引——因为空间索引只响应ST_函数族和&&操作符。
关键限制：
-
SPATIAL索引仅支持MyISAM（旧版）和InnoDB（5.7.5+），且列必须声明为NOT NULL - 不能用
ORDER BY或GROUP BY直接对空间列排序，需配合ST_X()/ST_Y()提取坐标 -
EXPLAIN中type显示为spatial而非ref或range，key字段值为索引名，但rows估算极不准确
FULLTEXT查询触发倒排索引+自然语言解析流程
FULLTEXT索引不按B+Tree的“有序键扫描”执行，而是启用独立的全文检索子系统：先对查询词做分词（默认空格/标点切分，InnoDB还支持ngram或mechanical分词器），再查倒排索引（inverted index）定位包含该词的文档ID，最后按相关性打分（RELEVANCE）排序。所以MATCH(col) AGAINST('apple banana')不是找同时含两个词的行，而是分别查出含apple和banana的行集，再做交集或加权合并。
典型踩坑：
- 短词（默认
ft_min_word_len=4）被忽略，'cat'查不到，改配置需重启MySQL并重建索引 -
AGAINST('apple*')通配需在末尾，且*不匹配空格，'apple pie'不会被'apple*'捕获 - InnoDB的
FULLTEXT不支持BOOLEAN MODE中的+/-前缀（除非显式指定IN BOOLEAN MODE） -
WHERE MATCH() AGAINST()不能和其他AND条件混合使用索引，AND created_at > '2025-01-01'会导致全文索引失效，必须用子查询或覆盖索引补救
普通索引走B+Tree标准路径，其他两类绕过该路径
普通索引、唯一索引、主键索引、联合索引都共享同一套B+Tree查找逻辑：从根节点开始，按键值大小逐层下推到叶子节点，再取rowid或主键值回表。而SPATIAL和FULLTEXT是存储引擎层面的“插件式索引”，它们的ha_*接口实现完全独立于handler::index_read流程。这意味着：
- 优化器无法统一估算
rows，EXPLAIN对这两类索引的rows列常为1或NULL - 无法用
FORCE INDEX强制走FULLTEXT或SPATIAL，语法直接报错 - 联合索引里混入
GEOMETRY或TEXT列会失败，因为B+Tree不支持这些类型作为索引列（除非前缀）
真正容易被忽略的是：即使你写了SELECT * FROM t WHERE geom_col && ST_Point(1,1)，如果表是InnoDB且MySQL版本SPATIAL索引都不尝试用，而不是“用得不好”。
