说到 MySQL，存储引擎之间没有可比性，只是它分为两个基本类别：

• 事务性（符合 ACID）

• 非交易性

• MySQL features the use of several storage engines

• InnoDB (default as of MySQL 5.5)
• MyISAM (default prior to MySQL 5.5)
• ARCHIVE
• BLACKHOLE
• CSV
• MEMORY
• MRG_MYISAM
• FEDERATED
• NDB a.k.a. MySQL Cluster
• http://www.mysql.com/products/cluster/mysql-cluster-datasheet.pdf)

至于列出的存储引擎，唯一符合 ACID 的引擎是 InnoDB 和 NDB。为什么这很重要？两个原因：

• 除了基本的磁盘 I/O、CPU 使用率和整体吞吐量之外，其他存储引擎根本无法受益于更多内核的存在。
• 每个非事务性存储引擎的代码基本上都规定了 14 个内部操作，而不管存储引擎如何，它的设计并不是为了利用多个内核的访问。

MySQL 5.5 下的 InnoDB、InnoDB Plugin）和 Percona Server 的 XtraDB 具有可以设置的选项以访问多个内核（Percona Server 一直在这样做）。事实上，Percona 在 MySQL 源代码的每个新 GA 版本中注入了大约 30,000 行代码，专门用于 InnoDB 的性能提升。我们可以肯定，Oracle 已经从他们自己的智囊团中加入了自己的增强功能，以便在 InnoDB 中运行以进行多核操作（从 MySQL 5.1.38 开始）。

由于需要结合行/页锁定对数据执行MVCC，因此现在可以检测、测量和配置事务性能。

更新 2011-09-20 08:03 EDT

关于受益于所有内核的 InnoDB，我们需要保持洞察力。核心还必须处理数据库服务器中的其他事务（操作系统、磁盘、内存、应用程序、监控等）。对于那些预算有限的人来说，许多人倾向于拥有一个数据库服务器，它还提供 NFS、来自 Munin 的监控、对 JBoss、PHP 的应用程序支持，等等。如果您希望 MySQL，更具体地说是 InnoDB，使用更多内核，则数据库服务器必须专门用于 MySQL，而 OS/Disk/Memory 必须仅倾向于 MySQL。从这个角度来看，毫无疑问，InnoDB 将使用更多的核心。

至于 InnoDB 插件，提到它只是为了展示早期的举措，以便在 MySQL 方面拥有更好的 InnoDB（呃，Oracle。抱歉，还没有说出口）。从 MySQL 5.1.38 开始，召唤更多核心活动的新变量变得明显。

例如，innodb_read_io_threads和innodb_write_io_threads（都是从 MySQL 5.1.38 开始）为读取和写入分配指定数量的线程。默认值为 4，最大值为 64。默认值和最大值设置如此不同 (4 - 64) 表明InnoDB 与您配置的一样多线程和核心密集型！！！

Percona 领导了通过 InnoDB 解决 MySQL 社区访问更多内核的需求。因此，MySQL 开始效仿。我不得不承认，Oracle (yuck) 为更多核心活动做出了必要的改进。