该用B-Tree索引而非哈希索引的情况是：需支持范围查询（>、BETWEEN）、ORDER BY、GROUP BY或前缀匹配时；因哈希索引仅支持等值查询且仅Memory引擎原生支持，MyISAM/InnoDB强制使用B-Tree。
什么时候该用 B-Tree 索引而不是哈希索引
B-Tree 是 MySQL 默认且最通用的索引类型，适用于 WHERE、ORDER BY、GROUP BY 和范围查询（如 >、BETWEEN）。哈希索引仅在 Memory 引擎中原生支持，且只支持等值查询（= 或 ），不支持范围、排序或前缀匹配。
- MyISAM/InnoDB 表一律用 B-Tree，别想着手动切哈希索引——它们根本不支持
- Memory 表若只做点查（如配置表缓存），可显式建
HASH索引：CREATE INDEX idx ON t (col) USING HASH，但一旦加了ORDER BY col，优化器就直接忽略它 - InnoDB 的自适应哈希索引（AHI）是自动的、不可控的，不是你建的索引，别把它和用户定义索引混淆
全文索引（FULLTEXT）只在特定场景生效
FULLTEXT 索引专为自然语言文本搜索设计，仅支持 MyISAM 和 InnoDB（5.6+），且只能用于 CHAR、VARCHAR、TEXT 列。它不走传统 B-Tree 查找路径，而是依赖内建分词器和倒排索引结构。
- 必须用
MATCH() AGAINST()语法才能触发，写成WHERE content LIKE '%关键词%'完全不走全文索引 - 默认最小词长是 4（
ft_min_word_len），搜 “go” “ai” 这类短词会直接被过滤掉，改配置需重启 MySQL 并重建索引 - 停用词（如 “the”、“and”）默认被忽略，不能用于精确匹配场景；需要精确子串定位（如日志行匹配），老实用
LIKE+ 前导通配符外加覆盖索引缓解
空间索引（SPATIAL）不是给经纬度“凑合用”的
SPATIAL 索引只支持 GEOMETRY 类型列（如 POINT、POLYGON），底层用 R-Tree 实现，专为地理围栏、邻近查询（ST_DWithin、ST_Contains）优化。拿它存普通浮点型经纬度字段（DECIMAL(10,8)）毫无意义，也不会生效。
- 建索引前必须确保列类型是
POINT，且用ST_PointFromText('POINT(116.4 39.9)')插入，不能直接插字符串或数字 - 查询必须用 GIS 函数，例如：
WHERE ST_Distance(location, ST_PointFromText('POINT(116.4 39.9)')) ；写成 <code>WHERE lat > 39.8 AND lat 就是普通 B-Tree 查询 - 如果只是简单查“附近 5km”，又不想引入 GIS 复杂度，更轻量的做法是先用四叉树编码（如 Geohash）转成字符串，再建普通 B-Tree 索引 + 前缀匹配
唯一索引与主键索引的物理存储差异常被忽略
InnoDB 中，主键索引（聚簇索引）直接决定数据行的物理存储顺序；而唯一索引（包括 UNIQUE 约束）是二级索引，叶子节点存的是主键值，不是行指针。这意味着：查唯一索引后还需回表一次（除非覆盖索引），而主键查询一步到位。
- 不要为了“看起来唯一”就随便加
UNIQUE—— 若该列更新频繁（如用户邮箱反复修改），会导致二级索引分裂+主键索引连锁更新，写放大明显 - 联合唯一索引（
UNIQUE(a,b)）对WHERE a = ?有效，但对WHERE b = ?无效；顺序很重要，别按“业务直觉”排，得按查询频率和选择性排 - 如果表没有显式主键，InnoDB 会悄悄创建隐藏的 6 字节 ROWID 当聚簇索引键——这会让所有二级索引变大，且无法预测排序行为，务必显式定义主键
