mysql索引有哪些类型_mysql索引分类说明

聚簇索引优先选主键，无主键时选第一个非空唯一列，否则用隐藏rowid；InnoDB中主键索引通常但不必然为聚簇索引，MyISAM不支持聚簇索引。

主键索引和唯一索引，到底谁才是聚簇索引？

主键索引不等于聚簇索引——这是最容易混淆的点。InnoDB 中，聚簇索引（Clustered Index）决定数据行的物理存储顺序，而它**优先选主键**；但若表没定义主键，InnoDB 会找第一个 UNIQUE 非空列；都找不到，就悄悄生成一个隐藏的 rowid 作为聚簇索引。所以，PRIMARY KEY 索引在绝大多数情况下是聚簇索引，但不是“因为叫主键所以一定是”，而是“因为被选中了所以成了聚簇索引”。

• 建表时没设主键，又加了 UNIQUE (email)，那这个 email 就可能变成聚簇索引——数据按 email 排序存放
• UNIQUE 索引允许 NULL，但只要含 NULL 的列就不会被选为聚簇索引（InnoDB 要求聚簇索引列非空）
• MyISAM 完全不支持聚簇索引，它的所有索引都是非聚簇的，叶子节点只存磁盘地址

B+Tree 索引为什么能扛住高并发查询？

mysql 默认用 B+Tree，不是因为它“高级”，而是它在磁盘 I/O、范围扫描、排序这三件事上做到了平衡。B+Tree 所有 key 都落在叶子节点，且叶子节点用双向链表连起来，这就意味着：WHERE age BETWEEN 25 AND 35、ORDER BY created_at DESC LIMIT 10 这类操作可以直接在叶子层顺序遍历，不用反复跳转非叶节点。

• 不要误以为 B+Tree 支持“跳过前导列”：索引 (a, b, c)，WHERE b = 2 AND c = 3 是用不上这个索引的
• LIKE 'abc%' 可走索引，LIKE '%abc' 或 LIKE '%abc%' 不行（除非启用了全文索引或 ngram 插件）
• InnoDB 的二级索引叶子节点存的是主键值，不是行指针——这意味着回表成本取决于主键长度；用 BIGINT 当主键比 char(32) UUID 更省空间、更快定位

Hash 索引真快吗？别在 InnoDB 里手动建

Hash 索引查 = 确实接近 O(1)，但它在 MySQL 里基本是个“幻影功能”。MEMORY 引擎支持显式创建 Hash 索引，但 InnoDB **不支持用户创建 Hash 索引**；它只有“自适应哈希索引”（AHI），由引擎自己判断热点页是否值得缓存成哈希结构——你既不能开，也不能关，更不能指定哪列建。

• 试图执行 CREATE INDEX idx ON t(a) using HASH 在 InnoDB 表上会报错：Error 1064 (42000): Syntax error
• AHI 是自动的、临时的、不可控的，且只对等值查询生效；一旦查询模式变化（比如加了 ORDER BY），AHI 就失效
• 真要极致等值查询性能，且能接受牺牲范围能力，可考虑把热数据导出到 MEMORY 表，再建 Hash 索引，但要注意数据持久性风险

全文索引不是“给文本字段加个索引”那么简单

FULLTEXT 索引底层是倒排索引，不是 B+Tree，所以行为完全不同。它不加速 LIKE，也不支持普通 WHERE 条件；必须用 MATCH() AGAINST() 语法，且默认启用自然语言模式（停用词过滤、相关性打分）。

• InnoDB 的全文索引从 5.6.4 开始支持，但中文需配合 ngram 或 mechanical 分词插件，否则一个汉字就是一个词，效果极差
• select * FROM articles WHERE content LIKE '%数据库%' —— 加了全文索引也完全没用
• 最小词长默认是 4（innodb_ft_min_token_size），搜 “SQL” 会直接被忽略，改配置需重启实例，且影响所有表

真正难的从来不是“有多少种索引”，而是面对一条慢查询，得快速判断：它走的是哪个索引路径？有没有隐式类型转换让索引失效？二级索引回表是不是成了瓶颈？这些细节藏在 EXPLAIN format=jsON 的 used_columns 和 key_parts 里，而不是分类列表中。