MySQL的时间线
在选择MySQL版本的时候，了解一下版本的变迁历史是有帮助的。对于怀旧者也可以享受一下过去的好日子里是怎么使用MySQL的。
版本3.23 (2001)
一般认为这个版本的发布是MySQL真正“诞生”的时刻，其开始获得广泛使用。在这个版本，MySQL依然只是一个在平面文件（Flat File)上实现了SQL査询的系统。但一个重要的改进是引入MyISAM代替了老旧而且有诸多限制的ISAM引擎。InrioDB引擎也已经可以使用，但没有包含在默认的二进制发行版中，因为它太新了。所以如果要使用InnoDB，必须手工编译。版本3.23还引入了全文索引和复制。复制是MySQL成为互联网应用的数据库系统的关键特性（killer feature)。
版本4.0 (2003)
支持新的语法，比如UNION和多表DELETE语法。重写了复制，在备库使用了两个线程来实现复制，避免了之前一个线程做所有复制工作的模式下任务切换导致的问题。InnoDB成为标准配备，包括了全部的特性：行级锁、外键等。版本4.0中还引入了查询缓存（自那以后这部分改动不大），同时还支持通过SSL进行连接。
版本4.1 (2005)
引入了更多新的语法，比如子査询和INSERT ON DUPLICATE KEY UPDATE。开始支持UTF-8字符集。支持新的二进制协议和prepared语句。
版本5.0 (2006)
这个版本出现了一些“企业级”特性：视图、触发器、存储过程和存储函数。老的ISAM引擎的代码被彻底移除，同时引入了新的Federated等引擎。
版本5.1 (2008) '
这是Sun收购MySQL AB以后发布的首个版本，研发时间长达五年。版本5.1引入了分区、基于行的复制，以及plugin API (包括可插拔存储引擎的API)。移除了BerkeyDB引擎，这是MySQL最早的事务存储引擎。其他如Federated引擎也将被放弃。同时Oracle收购的InnoDB Oy发布了InnoDB plugin。
版本5.5 (2010)
这是Oracle收购Sun以后发布的首个版本。版本5.5的主要改善集中在性能、扩展性、复制、分区、对微软Windows系统的支持，以及一些其他方面。InnoDB成为默认的存储引擎。更多的一些遗留特性和不建议使用的特性被移除。增加了PERFORMANCE_SCHEMA库，包含了一些可测量的性能指标的增强。增加了复制、认证 和审计API。半同步复制（semisynchronous replication)插件进入实用阶段。Oracle还在2011年发布了商用的认证插件和线程池（thread pooling)。InnoDB在架构方面也做了较大的改进，比如多个子缓冲池（bufferpool)。
版本5.6（这里先省略）
版本5.7
版本8.0
简单总结一下MySQL的发展史：早期的MySQL是一种破坏性创新,有诸多限制，并且很多功能只能说是二流的。但是它的特性支持和较低的使用成本，使得其成为快速增长的互联网时代的杀手级应用。在5.x版本的早期，MySQL引入了视图和存储过程等特性，期望成为“企业级”数据库，但并不算成功，成长并非一帆风顺。从事后分析来看，MySQL5.0充满了bug,直到5.0.50以后的版本才算稳定。这种情况在MySQL5.1也依然没有太多改善。版本5.0和5.1的发布都延期了许多时日，而且Sun和Oracle的两次收购也使得社区人士有所担心。但我们认为事情还在按部就班地发展，MySQL5.5可以说是MySQL历史上质量最髙的版本。Oracle收购以后帮助MySQL更好地往企业级应用的方向发展，MySQL5.6也承诺在功能和性能方面将有显著提升。
提到性能，我们可以比较一下在不同时代MySQL的性能测试的数据。在目前的生产环境中4.0及更老的版本已经很少见了，所以这里不打算测试4.1之前的版本。另外，如此多的版本如果要做完全等同的测试是比较困难的，具体原因将在后面的讨论。书作者尝试设计了多个测试方案来尽量保证在不同版本中的基准一致，并为此做了很多努力。
表1-2显示了在服务器层面不同并发下的每秒事务数的测试结果。
| 表1-2：多个不同MySQL版本的只读测试 | ||||||
| 线程数 | MySQL 4.1 | MySQL 5.0 | MySQL 5.1 | MySQL 5.1 with InnoDB plugin | MySQL 5.5 | MySQL 5.6 |
| 1 | 686 | 640 | 596 | 594 | 531 | 526 |
| 2 | 1307 | 1221 | 1140 | 1139 | 1077 | 1019 |
| 4 | 2275 | 2168 | 2032 | 2043 | 1938 | 1831 |
| 8 | 3879 | 3746 | 3606 | 3681 | 3523 | 3320 |
| 16 | 4374 | 4527 | 4393 | 6131 | 5881 | 5573 |
| 32 | 4591 | 4864 | 4698 | 7762 | 7549 | 7139 |
| 64 | 4688 | 5078 | 4910 | 7536 | 7269 | 6994 |
很容易将表1-2的数据以图的方式展示出来。
在解释结果之前，需要先介绍一下测试环境。测试的机器是Cisco UCS C250,两颗6核CPU,每个核支持两个线程，内存为384GB，测试的数据集是2.5GB，所以MySQL的buffer pool设置为4GB。采用SysBench的read-only只读测试进行压测，并采用InnoDB存储引擎，所有的数据都可以放入内存，因此是CPU密集型（CPU-bound)的测试。每次测试持续60分钟，每10秒获取一次吞吐量的结果，前面900秒用于预热数据，以避免预热时的I/O影响测试结果。
现在来看看结果，有两个很明显的趋势。第一个趋势，采用了InnoDB plugin的版本， 在高并发的时候性能明显更好，可以说InnoDB plugin的扩展性更好。这是可以预期的结果，旧的版本在高并发时确实存在问题。第二个趋势，新的版本在单线程的时候性能比旧版本更差。一开始可能无法理解为什么会这样，仔细想想就能明白，这是一个非常简单的只读测试。新版本的SQL语法更复杂，针对复杂査询增加了很多特性和改进，这对于简单査询可能带来了更多的开销。旧版本的代码简单，对于简单的査询反而会更有利。
原计划做一个更复杂的不同并发条件下的读写混合场景的测试（类似TPC-C)，但要在不同版本间做到可比较基本是不可能的。一般来说，新版本在复杂场景时性能有更多的优化，尤其是髙并发和大数据集的情况下。
那么该如何选择版本呢？这更多地取决于业务需求而不是技术需求。理想情况下当然是版本越新越好，当然也可以选择等到第一个bug修复版本以后再采用新的大版本。如果应用还没有上线，也可以采用即将发布的新版本，以尽可能地延迟应用上线后的升级操作。
当然，现在8.0也已经发布，可以去官网查看最新的mysql信息。
