InnoDB聚簇索引查SELECT *用主键时无需回表，因叶子节点存整行数据；MyISAM所有索引非聚簇，查主键也需二次寻址；其“快”仅限全表扫描、索引覆盖等特定场景。
聚簇索引查 SELECT * 时不用回表
InnoDB 的聚簇索引叶子节点直接存整行数据，所以用主键查 SELECT * 时，一次 B+ 树查找就拿到全部字段。MyISAM 所有索引（包括主键）都是非聚簇的，叶子节点只存数据文件的物理地址，哪怕你查的是主键，也得先读索引、再根据地址去数据文件里 fseek 一次——这多一次随机 I/O。
MyISAM 的“快”只在特定场景成立
MyISAM 查询看起来快，往往出现在以下情况：
- 全表扫描（
SELECT * FROM t），因为 MyISAM 数据文件是连续存储的，顺序读效率高； - 只查索引覆盖字段（如
SELECT id FROM t WHERE name = 'x'），且name有索引； - 并发写少、无事务开销的只读报表表。
SELECT * + 非主键条件（比如 WHERE product_name = 'Laptop'），MyISAM 就要寻址跳转，而 InnoDB 的辅助索引虽然也要回表，但主键通常短小紧凑（如 INT），回表路径更可预测，缓存局部性更好。InnoDB 的“慢”常被误归因于索引，其实是事务和锁的代价
MyISAM 没 MVCC、不记 undo log、不维护事务视图，查询时跳过所有版本判断逻辑；InnoDB 每次查询都要比对当前事务 ID 和每行的 DB_TRX_ID，还要检查可见性。这不是索引结构的问题，而是功能差异带来的开销。你在 EXPLAIN 里看到的 type: ref 或 range 耗时相近，但实际执行阶段 InnoDB 多了版本过滤步骤。如果关掉事务（比如用 SET autocommit = 1 并避免显式 BEGIN），差距会明显收窄。
主键设计不当会让 InnoDB 聚簇优势反成劣势
聚簇索引的物理排序特性是一把双刃剑：
- 用自增
id当主键：新行总追加在末尾，页分裂少，缓存友好； - 用
UUID或随机字符串当主键：数据物理位置跳跃，B+ 树频繁分裂、页碎片多、缓冲池命中率低，此时 MyISAM 的线性地址跳转反而更稳。
真正影响查询速度的，从来不是“聚簇 or 非聚簇”这个标签，而是你的查询是否触发回表、是否命中缓存、主键是否导致物理碎片、以及你是否真的需要事务——这些细节，比背概念重要得多。
