主键索引和唯一索引，到底谁才是聚簇索引？
主键索引不等于聚簇索引——这是最容易混淆的点。InnoDB 中，聚簇索引（Clustered Index）决定数据行的物理存储顺序，而它**优先选主键**；但若表没定义主键，InnoDB 会找第一个
UNIQUE非空列；都找不到，就悄悄生成一个隐藏的
rowid作为聚簇索引。所以，
PRIMARY KEY索引在绝大多数情况下是聚簇索引，但不是“因为叫主键所以一定是”，而是“因为被选中了所以成了聚簇索引”。 建表时没设主键，又加了
UNIQUE (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 errorAHI 是自动的、临时的、不可控的，且只对等值查询生效；一旦查询模式变化（比如加了
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里，而不是分类列表中。
