主键查询快是因为InnoDB主键索引即聚簇索引，叶子节点直接存储整行数据，查主键只需一次B+树查找即可获取全部字段，无需回表；而二级索引叶子节点仅存索引列和主键值，查询需二次查找。
主键查询快，不是因为“用了索引”，而是因为数据就长在索引里——InnoDB 的主键索引就是聚簇索引，查主键 = 直接定位到整行数据的物理位置。
为什么主键等值查询只需一次 B+ 树查找
在 InnoDB 中，PRIMARY KEY 对应的 B+ 树，其叶子节点直接存储完整的行记录（包括所有字段），而非仅索引列或指针。这意味着：
- 执行
SELECT * FROM user WHERE id = 123时，MySQL 只需遍历一次 B+ 树，落到对应叶子页，整行数据就躺在那儿，无需额外动作 - 对比二级索引（如
INDEX idx_name）：它的叶子节点只存name值 + 对应的主键值，查完还得拿着这个主键再回聚簇索引找一遍——这就是“回表”，多一次 I/O - 聚簇索引天然支持范围扫描（如
WHERE id BETWEEN 100 AND 200），因为数据在磁盘上按主键物理有序，连续页可顺序读取
主键必须是 InnoDB 才生效，MyISAM 完全不认这套
聚簇索引是 InnoDB 存储引擎的实现机制，MyISAM 没有聚簇索引概念：
- MyISAM 的主键索引和普通索引结构一致：叶子节点只存数据行的物理地址（.MYD 文件中的偏移量），查主键也要先查索引、再寻址读数据——本质上仍是“索引+回查”，不省步骤
- 如果你用的是 MyISAM 表，哪怕建了
PRIMARY KEY，也不会获得聚簇索引带来的性能优势 - 检查方式：
SHOW TABLE STATUS LIKE 'your_table'，确认Engine字段是InnoDB
没有显式主键时，InnoDB 会悄悄给你补一个
聚簇索引不可缺失，InnoDB 会按优先级自动选一个：
- 显式定义的
PRIMARY KEY→ 用它 - 没主键但有
NOT NULL UNIQUE列 → 选第一个作为聚簇索引 - 以上都没有 → 隐式生成一个 6 字节的
ROW_ID（自增、不可见），并以此构建聚簇索引 - 隐患：隐式
ROW_ID无法被 SQL 引用，且并发插入可能引发锁竞争；更糟的是，如果后续加了主键，InnoDB 要重建整个聚簇索引（耗时、锁表）
聚簇索引的物理顺序直接影响写入性能
数据在磁盘上按主键值排序存放，这带来两个关键影响：
- 自增主键（如
id BIGINT UNSIGNED AUTO_INCREMENT）写入最快：新行总追加在最后一页，避免页分裂；随机主键（如 UUID）会导致频繁页分裂和碎片，写入变慢、空间利用率下降 - 范围查询（
ORDER BY id、LIMIT分页）能利用物理有序性，减少排序和随机 I/O - 更新主键值（
UPDATE ... SET id = new_id）代价极高：相当于删旧行 + 插新行，触发两次 B+ 树调整，还可能引起锁升级
真正容易被忽略的点是：聚簇索引的优势只在「主键本身参与查询条件」时才完全释放；一旦你用 WHERE name = ? 查，哪怕 name 是唯一索引，也绕不开回表——这时候就得靠覆盖索引或调整查询逻辑来规避。
