为什么数据全在缓冲池时InnoDB全表扫描仍远慢于MyISAM与Memory引擎

核心原因是三个引擎的设计定位不同，InnoDB为了支持事务、崩溃安全、行级锁等企业级特性，引入了大量额外开销，在无索引全表扫描的极端场景下这些开销被完全放大，具体可分为四点：

• 行存储与解析开销差异
  InnoDB采用聚簇索引结构，每一行除了用户数据外，还附带6字节事务ID、7字节回滚指针、行头标记、NULL位图等元数据，即使所有字段都是NOT NULL，也存在固定元数据开销；同时InnoDB的数据页还包含页头、页目录、校验和等额外信息，解析每行数据的运算量远高于另外两个引擎。
  本次测试用的表所有字段都是定长类型，MyISAM作为堆表采用定长行格式存储，行数据之间没有额外元数据，直接通过固定偏移量即可快速读取，解析成本极低。Memory引擎直接在内存中以最简化的固定结构存储数据，解析开销最小。
• MVCC一致性检查开销
  InnoDB支持事务和MVCC，所有只读查询都需要先构建一致性读视图，逐行对比事务ID判断数据可见性，1000万行的逐行检查累计开销非常可观。而MyISAM和Memory引擎不支持事务，完全没有MVCC逻辑，读取时不需要做任何可见性校验，拿到数据即可直接返回。你提供的SHOW ENGINE InnoDB STATUS输出中也能看到读视图相关的统计，这部分是核心开销来源之一。
• 缓冲池管理开销
  InnoDB自行实现缓冲池管理，通过LRU链表维护页的生命周期，即使数据已经完全加载到缓冲池，每次访问数据页都需要加锁更新LRU元数据、统计访问信息，测试中每次查询innodb_buffer_pool_read_requests增长约10M，就是对应1000万次左右的缓冲池访问操作，累计开销不可忽视。MyISAM依赖操作系统页缓存存储热点数据，没有额外的用户态缓存管理开销；Memory引擎数据直接存储在内存中，不需要缓存层管理，访问开销更低。
• 锁机制开销
  InnoDB即使是只读查询，也需要加表级意向共享锁，读取过程中还要维护行级锁的相关元数据。而MyISAM和Memory引擎只支持表锁，只读查询仅需要加一次共享表锁即可完成全表扫描，没有逐行的锁相关处理开销。

以上开销都是InnoDB实现ACID特性、行级锁、崩溃安全等能力的必要代价，属于设计层面的权衡，并非故障或配置问题。这种巨大的性能差异仅出现在无索引全表扫描的极端场景下，常规带索引的查询场景下，扫描行数大幅减少，三者的性能差距会大幅缩小。

内容的提问来源于stack exchange，提问作者Alex K.