聚簇索引优先选主键，无主键时选第一个非空唯一列，否则用隐藏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），由引擎自己判断热点页是否值得缓存成哈希结构——你既不能开，也不能关，更不能指定哪列建。
