聚簇索引叶子节点直接存储整行数据，非聚簇索引叶子节点仅存主键值或物理地址，InnoDB主键索引即聚簇索引，查主键时一次查找即可获取全部字段；MyISAM所有索引均为非聚簇索引，即使主键查询也需先查索引再按物理偏移量寻址，本质是两次独立磁盘访问。
聚簇索引的叶子节点直接存数据，非聚簇索引必须回表
InnoDB 的主键索引是聚簇索引，PRIMARY KEY 对应的 B+ 树叶子节点里就放着整行数据。查 SELECT * FROM t WHERE id = 123 时，一次索引查找就拿到全部字段，不用再跳转。
MyISAM 的所有索引（包括主键）都是非聚簇索引，叶子节点只存 .MYD 文件里的物理偏移量。哪怕你按主键查，也得先读索引拿到地址，再去数据文件里 fseek 一次——这算一次“回表”，但本质是两次独立磁盘寻址。
- InnoDB 回表是二次 B+ 树查找（先查二级索引得
PRIMARY KEY，再拿该值去聚簇索引里查），随机 IO 概率高 - MyISAM 回表是直接按地址读
.MYD，局部性更好，但前提是数据文件没碎片、缓存命中率高 - 真实场景中，InnoDB 的 buffer pool 缓存的是页（page），而 MyISAM 只缓存索引（
key_buffer_size），数据文件靠系统 page cache，稳定性差
范围查询时聚簇索引天然有序，非聚簇索引需额外排序
聚簇索引强制数据按主键物理排序，SELECT * FROM orders WHERE created_at BETWEEN '2025-01-01' AND '2025-01-31' 如果 created_at 是二级索引，InnoDB 还是要回表；但如果用 id 或联合主键覆盖时间范围，就能利用物理连续性批量读页，减少 IO 次数。
MyISAM 的数据文件本身无序，即使走 created_at 索引，查到的物理地址也是离散的，顺序读失效，ORDER BY 或 LIMIT 很可能触发 filesort。
- 聚簇索引的范围扫描（
type: range）常伴随Using index，尤其当查询字段全在主键或覆盖索引里 - MyISAM 即使建了
INDEX(a,b)，ORDER BY a,b也不保证物理有序，引擎不保证排序结果稳定 - MyISAM 表导出再导入后，
.MYD文件顺序丢失，SELECT * LIMIT 10结果可能每次都不一样
主键缺失时 InnoDB 仍能组织数据，MyISAM 容易隐式失效
InnoDB 表没显式 PRIMARY KEY，会悄悄加一个隐藏的 6 字节 _rowid（类型为 BIGINT），确保聚簇索引存在。这个隐藏主键不可见、不可引用，但真实参与排序和回表。
MyISAM 完全不强制主键，SHOW CREATE TABLE 里没有 PRIMARY KEY 就真没有。很多 ORM 或旧客户端默认假设“有主键”，生成的 SQL 可能含 ORDER BY id 或 JOIN ON id，运行时报错或逻辑错乱。
- 隐藏主键会让
INSERT性能略降（多写 6 字节 + 维护 B+ 树），但换来的是查询结构稳定 - MyISAM 表迁移后若忘记重建主键，
WHERE id = ?可能走全表扫描，且优化器无法预估行数，EXPLAIN的rows常为 0 或错误值 -
ALTER TABLE t ENGINE=InnoDB不加ADD PRIMARY KEY，等于把隐患打包带走——隐藏主键无法被业务逻辑利用
事务与 MVCC 带来的开销不是索引结构问题，而是功能代价
有人说 “MyISAM 查询快是因为没 MVCC”，这混淆了因果。InnoDB 的版本链判断、undo log 查找、可见性检查确实耗 CPU，但这和索引是否聚簇无关，而是事务引擎的固有成本。
真正影响查询速度的，是：聚簇索引让单点查询少一次树查找；让范围扫描更贴近磁盘顺序；让二级索引体积更小（因无需重复存储主键以外的数据）；让 DROP INDEX 不影响数据布局。
- MyISAM 的快，建立在无事务、无崩溃恢复、无行锁、数据静态的前提下；一旦有并发写入，
LOCK TABLES会让查询排队 - InnoDB 的慢，常出现在主键设计不合理时：比如用
UUID当主键，导致插入时页分裂严重，buffer_pool命中率骤降 - 别只看
EXPLAIN的type，重点盯Extra：出现Using filesort或Using temporary时，索引结构再优也救不了
聚簇索引更快不是因为“B+ 树更高级”，而是它把数据组织方式和查询模式对齐了——只要你的查询符合主键或覆盖索引路径，就能省掉最贵的那一步：寻址。但一旦绕开主键、大量回表、或主键离散，InnoDB 的优势就会被事务开销吃掉。实际调优时，得先看 EXPLAIN FORMAT=JSON 里的 access_type 和 attached_condition，而不是背结论。
