什么时候该用 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 当聚簇索引键——这会让所有二级索引变大，且无法预测排序行为，务必显式定义主键
