1 MySQL不同版本间的性能比较
不知道大家初次见到MySQL是何种感觉，反正我见到MySQL3.23时很不以为然，没有视图，没有事务，没有触发器，没有子查询，没有存储过程，没有……，懒得提了，但是要说是今天MySQL5.0的能力已经得到了很大的提升，至少上面说明的这些问题，MySQL已经解决了大部分了。
1.1比较的版本
选择比较的版本是3.23版本,4.0版本, 4.1版本，5.0 Beta版本。其中3.23版本为MySQL的最早的可用版本，XXX等产品也一直在使用，4.0为MySQL支持查询缓冲的版本，也有很多产品使用。MySQL 4.1和5.0版本为较新的版本，支持一些新的特性。
MySQL的安装可以使用源代码自己编译，也可以使用MySQL官方提供的编译版本，相对而言官方提供的静态编译版本比较容易安装(动态编译的版本要依赖glibc库版本)。
另外MySQL提供从4.1以后的提供了Intel C++ Compiler编译的版本，据称Intel C++ Compiler的版本比GCC编译的版本速度要快20%以上，所以也找来看看。
从下面这个表，我们也可以看出MySQL发展史和各个版本的基本特点，可以看出MySQL从一个过家家类型的数据库开始越来越像一个成熟的商用数据库了。
表1 测试的版本
|
说明
|
版本特点
|
|
|
MySQL3.23.51
|
公司内部分产品使用的版本，
|
为自己用gcc编译
|
|
MySQL3.23.55
|
官房网站下载的3.23的gcc编译static版本
|
3.23的一个成熟版本
|
|
MySQL 4.0 gcc
|
官房网站下载的gcc编译static版本下载4.0版本，公司相当产品使用
|
提供了查询Cache
提供了FULLTEXT的文本检索索引
提供了嵌入式的MySQL
InnoDB开始成为内建引擎,InnoDB支持事务，外键，操作行锁定等特性
可以动态调整MySQL的某些运行参数, ”SET”
部分功能性能提升，如批量插入，
功能增加，如TRUNCATE，UNION查询等
|
|
MySQL 4.1 gcc
|
官房网站下载的gcc编译static版本
|
提供的新特性
子查询的功能，SELECT的嵌套
使用MYSQL_STMT加快了C/S通讯速度，
增加了一些新函数
|
|
MySQL 4.1 icc
|
官房网站下载的intel c++ 编译4.1版本，要intel的动态库支持
|
Intel C++编译的版本号称速度要快20%以上
|
|
MySQL 5.0 gcc (beta)
|
最新的MySQL版本，官房网站下载版本
从这个版本开始MySQL开始真正像一个商用数据库了。
MySQL5.0的正式颁布已经发布
|
提供很多成熟商业数据库的特性，
视图，以及相关一些管理功能
存储过程，光标
触发器，已经支持时间和事件触发
VARCHAR长度的增加
InnoDB支持分布式事务
支持一些新的存储引擎(ARCHIVE,只支持插入和查询操作，FEDERATED, 访问远程数据)
|
1.2测试的方法和结果
分别，插入，查询，修改，删除，1000000，5000000，10000000，条记录。尝试MySQL在不同的记录数量级别下的表现。表不进行压缩存储。
测试环境使用使用MyISAM数据库引擎，配置中比较关键的参数为，对于4.0后的查询版本使用查询Cache。同时为了模拟真实环境，记录二进制日志。
使用的关键参数为：
set-variable = key_buffer_size=384M
set-variable = query_cache_size=384M
set-variable = sort_buffer_size =1M
set-variable = read_buffer_size=1M
set-variable = table_cache=256
1.测试采用脚本分组进行，每次测试前删除掉原来的数据，同时删除掉二进制日志（可能flush-log一下更好）。每次操作前sleep 20秒。
2.插入记录为插入0-N条记录，每次单条插入。
3.查询为每次查询一条的N次查询。遍历所有的记录。查询使用主键作为查询条件。查询操作完成转储结果集的操作。
4.修改所有的数据，每个记录修改部分信息（4个字段），每次修改1条。
5.删除所有的数据，为每次单独删除。删除使用主键作为查询条件。
表2 数据文件的大小
|
记录条数
|
数据文件大小
|
索引文件大小
|
|
1000000
|
111999988
|
8209408
|
|
5000000
|
559999988
|
41036800
|
|
10000000
|
1119999988
|
82071552
|
测试的性能数据为：
表3 不同版本的表现的耗时
|
数据库
|
3.23.51
耗时(s)
|
3.23.55
耗时(s)
|
4.0
耗时(s)
|
4.1gcc
耗时(s)
|
4.1icc
耗时(s)
|
5.0
耗时(s)
|
|
插入1000000条记录
|
175
|
170
|
169
|
176
|
183
|
185
|
|
查询1000000条记录
|
208
|
203
|
282
|
306
|
323
|
345
|
|
改写1000000条记录
|
173
|
167
|
165
|
174
|
185
|
178
|
|
删除1000000条记录
|
183
|
169
|
172
|
179
|
188
|
184
|
|
插入5000000条记录
|
899
|
876
|
876
|
898
|
947
|
949
|
|
查询5000000条记录
|
1029
|
1014
|
1472
|
1595
|
1671
|
1773
|
|
改写5000000条记录
|
871
|
841
|
816
|
859
|
908
|
911
|
|
删除5000000条记录
|
914
|
855
|
958
|
976
|
1005
|
1006
|
|
插入10000000条记录
|
1811
|
1745
|
1758
|
1817
|
1896
|
1954
|
|
查询10000000条记录
|
2080
|
2033
|
3001
|
3257
|
3386
|
3607
|
|
改写10000000条记录
|
1884
|
1793
|
1844
|
1904
|
1969
|
2019
|
|
删除10000000条记录
|
1976
|
1897
|
1908
|
1982
|
2045
|
2102
|
表4 不同版本处理性能比较
|
数据库
|
3.23.51处理速度(条/s)
|
3.23.55处理速度 (条/s)
|
4.0处理速度
(条/s)
|
4.1gcc处理速度 (条/s)
|
4.1icc
处理速度
(条/s)
|
5.0Beta
处理速度
(条/s)
|
|
插入1000000条记录
|
5714.29
|
5882.35
|
5917.16
|
5681.82
|
5464.48
|
5405.41
|
|
查询1000000条记录
|
4807.69
|
4926.11
|
3546.10
|
3267.97
|
3095.98
|
2898.55
|
|
改写1000000条记录
|
5780.35
|
5988.02
|
6060.61
|
5747.13
|
5405.41
|
5617.98
|
|
删除1000000条记录
|
5464.48
|
5917.16
|
5813.95
|
5586.59
|
5319.15
|
5434.78
|
|
插入5000000条记录
|
5561.74
|
5707.76
|
5707.76
|
5567.93
|
5279.83
|
5268.70
|
|
查询5000000条记录
|
4859.09
|
4930.97
|
3396.74
|
3134.80
|
2992.22
|
2820.08
|
|
改写5000000条记录
|
5740.53
|
5945.30
|
6127.45
|
5820.72
|
5506.61
|
5488.47
|
|
删除5000000条记录
|
5470.46
|
5847.95
|
5219.21
|
5122.95
|
4975.12
|
4970.18
|
|
插入10000000条记录
|
5521.81
|
5730.66
|
5688.28
|
5503.58
|
5274.26
|
5117.71
|
|
查询10000000条记录
|
4807.69
|
4918.84
|
3332.22
|
3070.31
|
2953.34
|
2772.39
|
|
改写10000000条记录
|
5307.86
|
5577.24
|
5422.99
|
5252.10
|
5078.72
|
4952.95
|
|
删除10000000条记录
|
5060.73
|
5271.48
|
5241.09
|
5045.41
|
4889.98
|
4757.37
|
比较图表如下：
图2
多个版本间的性能比较
从上面两张表可以看出，MySQL的简单查询，修改，插入，删除性能还是非常可圈可点的。在1000000的记录级别，效率也可以达到3000-6000条左右。
总体来看，除了查询，大家的性能其实都差不多。从4.0开始的版本，查询速度都有一个明显的下降，个人估计是由于4.0后MySQL支持查询Cache造成的，我的查询方式几乎不会利用到Cache数据，所以Cache不但没有帮助提高查询效率，反而降低了查询的效率。基于这个问题，我们后面单独对MySQL的Cache进行了单独的测试。
我在测试后惊讶的发现，最好的数据居然是mysql3.23.55的版本的性能。我只能猜测无数的功能堆加后，性能多少有下降，5.0Beta版本也的确排名最后。而对于现有使用的版本3.23.51和3.23.55版本的性能很接近。但是看来使用安装包版本比自己编译版本要好。
icc编译的版本没有想传言那样体现优势。我个人估计我的测试用例主要测试的是MySQL的I/O性能，而不是运算。icc的强项体现不出来。
即使到了10000000的数据量级别，查询和更新速度仍然可以接受。不想传说中那么恐怖。
插入速度的确快过查询速度。B树的重建索引速度大于查询的。？而且即使对于MySQL3.23的版本，查询的性能还是要落后于其他操作，个人估计是由于查询结果要返回结果集合造成的。
从这组数据我们可以发现，在数据量增加后，插入数据的性能变化很小，查询数据的性能成非常轻微的下降，这很好理解，这是由于查询的索引增大造成的。
个人觉得这些性能数据接近这些操作在MySQL在380G3上的极限性能。因为这些基本操作的瓶颈在都在I/O上，并发不可能提高这些性能[注]。倒是调整操作系统的参数和内核还可能有一些优化的余地。
当然改善硬件设备和关闭二进制日志等优化还是可以提高一些性能。
1.3 MySQL的版本
从上面的测试结果来，使用MyISAM引擎，MySQL的数据库的基本功能性能没有太多变化。MySQL后面的几个版本介绍说明有性能提高的地方也都不包括基本功能这块。
而对于4.0后提供的查询Cache这个功能，其实也是差强人意，（后面会着重讨论）。所以指望升级数据库大规模改善数据表的基础功能性能看来不现实。但考虑到4.0和4.1版本提供了一些新的功能，而且更加稳定。使用4.0以后的版本还是正确的选择[注]。
MySQL的升级版本其实比想像的容易，MyISAM,InnoDB的文件格式都是与位置无关的（当然操作系统的限制除外）。3.23的数据库升级4.0运行一个更改数据库权限表的脚步就可以万事大吉。而升级到4.1会有一些麻烦，4.1后的数据库的认证方式发生了变化，所以使用旧有的数据库客户端版本无法登陆。但可以通过修正新数据库的密码解决这个问题