聚簇索引是表数据按主键顺序物理存储，innodb中主键即聚簇索引，叶子节点存完整行；二级索引叶子存索引列+主键值，查非索引字段需回表；uuid主键易致页分裂；隐式类型转换会使索引失效。
聚簇索引的物理存储到底长什么样
聚簇索引不是“加了索引就聚簇”，而是指表数据本身按索引键顺序物理存储在磁盘上。InnoDB 中，PRIMARY KEY 自动成为聚簇索引；没定义主键时，InnoDB 会选第一个 NOT NULL UNIQUE 列；都不存在时，隐式生成 row_id 作为聚簇索引键。
这意味着：一次查询如果命中聚簇索引（比如 SELECT * FROM user WHERE id = 123），InnoDB 直接定位到对应的数据页，无需回表。但反过来，SELECT name FROM user WHERE id = 123 虽然也走聚簇索引，仍要读整行再提取 name 字段——因为数据页里存的是完整行记录。
- 聚簇索引的 B+ 树叶子节点存的是 完整数据行，不是指针
- 一张表只能有一个聚簇索引（物理顺序唯一）
-
INSERT频繁且主键非自增（如用 UUID）会导致页分裂加剧，写性能下降
非聚簇索引（二级索引）查数据为什么常要回表
非聚簇索引的 B+ 树叶子节点不存完整行，只存索引列 + 对应的 PRIMARY KEY 值（叫“书签”）。所以执行 SELECT * FROM user WHERE email = 'a@b.com'（email 是普通索引）时：
- 先查
email索引树，拿到匹配的id值（比如 456） - 再拿这个
id去聚簇索引树里二次查找，定位到真实数据页
这就是“回表”。它带来额外的 I/O 开销，也是为什么 SELECT * 在二级索引上代价高。
立即学习“Java免费学习笔记（深入）”；
避免回表的方法只有两个：
- 改成覆盖索引（如 SELECT id, email FROM user WHERE email = ?，且 email 索引包含 id —— 实际就是它本来就有）
- 或把查询字段全加进索引（INDEX idx_email_name (email, name)），但会增大索引体积
为什么 MySQL 8.0 的降序索引不影响聚簇索引行为
聚簇索引的排序逻辑由主键定义决定，和二级索引是否带 DESC 无关。声明 INDEX idx_created (created_at DESC) 只影响该索引树内部键值的存储顺序，其叶子节点仍存 created_at + 主键，回表逻辑不变。
真正影响聚簇索引物理顺序的，只有主键本身的定义方式：
-
id BIGINT PRIMARY KEY AUTO_INCREMENT→ 数据按id递增写入，页分裂少 -
id VARCHAR(36) PRIMARY KEY（UUID）→ 插入位置随机，容易页分裂、碎片多 - 复合主键如
(tenant_id, id)→ 数据按租户聚集，适合多租户场景，但单查id就无法利用聚簇优势
EXPLAIN 中 key_len 异常大？可能是隐式类型转换毁掉了索引
哪怕建了 INDEX idx_mobile (mobile)，执行 SELECT * FROM user WHERE mobile = 13800138000（传入数字而非字符串）时，MySQL 可能放弃使用该索引——因为字段是 VARCHAR，而查询值是数字，触发隐式类型转换，导致索引失效。
这时 EXPLAIN 显示 key_len 比预期大，甚至 type=ALL。验证方法：
SHOW WARNINGS;
会看到类似 Cannot use ref access on index 'idx_mobile' due to type or collation conversion 的提示。
正确做法始终让参数类型与字段一致：
- Java 中用
String.valueOf(mobile)传参，而不是直接传long - MyBatis 的
<if test="mobile != null and mobile != ''"></if>后面拼接的值必须是字符串 - SQL 里显式写成
WHERE mobile = '13800138000'
聚簇索引再好，也救不了被类型转换悄悄绕过的查询。
