[ MySQL ] MySQL vs SQL Server 2000 in Performance 5.0.24a
拿MySQL和SQL Server 2000在性能上做了个简单的比较测试。MySQL的版本为5.0,使用程序测试的地方,用的是ByteFX for MySQL的Provider。
1. 使用参数化的方式,每次Insert一条记录(No transaction)。
1. 使用参数化的方式,每次Insert一条记录(No transaction)。
Number of Records | Total Time | Average Number per Second | |
---|---|---|---|
SQL Server 2000 | 81534 | 39'' | 2090 |
MySQL | 81534 | 33'2'' | 41.14 |
2. 每次将100条Insert语句拼起来提交执行一次(不使用参数化方式,每次Batch insert,No transaction)。
Number of Records | Total Time | Average Number per Second | |
---|---|---|---|
SQL Server 2000 | 81534 | 33'' | 2470 |
MySQL | 81456 | 32'14'' | 42.12 |
3. 相同的表结构,数据也基本一样。SQL Server 2000的表中记录数为81534,MySQL的表中记录数为81456。
下面的操作中,MySQL用的是MySQL Query Browser,时间取的是MySQL Query Browser显示的总花费时间(不是那个??? rows fetched in ???s的时间,而是后面括号里的那个)。SQL Server 2000用的查询分析器执行操作,用Profiler监控执行时间。
Select *操作,SQL Server 2000平均用时0.606'',MySQL平均用时0.0218''。当然,SQL Server的0.606''应当包括存储引擎检索、传输返回数据的总时间;而MySQL的0.0218'',估计只是存储引擎检索数据的时间。在MySQL Query Browser中,Select *操作显示81456 rows feched in 3.4213s,这个时间应当包括存储引擎将81456条数据传输给MySQL Query Browser,以及MySQL Query Browser完成显示的时间。这样看来,在存储引擎方面,MySQL和SQL Server之间不太好比较;但要么是MySQL在数据传输机制方面的表现一般,或者是MySQL Query Browser在显示时的成本太高了。
在SQL Server 2000中,使用Primary Key(为Clustered Index) Select 位于表中间部分的一条记录,然后使用非索引唯一字段Select表最后一条记录(必须全表扫描)测试,发现SQL Server会因为缓存方面的原因(索引的缓存、实际数据页的缓存),Profiler监控到的结果不具备说明性。但SQL Server 2000在表数据为8万左右做全表扫描或者是使用索引访问数据,总体来说效率都是比较高的。
在MySQL中使用Primary Key Select位于表中间部分的一条记录,平均每次用时均为0.0004''。使用非索引唯一字段Select位于表中间一条记录,平均每次用时0.096''。使用非索引唯一字段Select表最后一条记录,平均每次用时0.099''。
在MySQL中,使用Select * from TableName limit 1000,20,平均每次用时0.0015'';使用limit 50000,20,平均每次用时0.0585'';使用limit 80000,20,平均每次用时0.0935''。看来MySQL中对limit关键字采取逐行扫描方式取指定的记录,因此随着起始基数的增大所用时间有所增加。
在MySQL中,使用Select * from TableName order by Primary Key asc的情况下, limit 1000,20、limit 50000,20、limit 80000,20的时间,跟上面的测试结果基本一样。使用Select * from TableName order by Primary Key desc的情况下,limit 1000,20、limit 50000,20、limit 80000,20的时间,基本都在0.013'',变化不大。
在MySQL中,使用Select * from TableName order by 非索引字段 desc情况下,limit 1000,20的时间,在0.7''和0.3''两个数字周围变动;limit 40000,20的时间,在1.5''和0.6''两个数字周围变动;limit 80000,20的时间,在0.7''-1.7''之间变动。
单从上面测试结果来看,MySQL在Select方面,效率非常高;在Order by方面效率一般;Insert数据时效率非常低。
当然,从SQL Server的机制方面来看,性能问题基本都发生在需要大内存运算的地方,例如大数据量情况下的Order操作、Hash / Merge Join操作、Group By等聚合操作。大数据量情况下的Join本人是非常不赞同的,不管是业务层面架构设计层面还是程序实现层面,都应当尽一切可能避免。但Order、聚合操作等倒是经常需要用到,有兴趣时再测测聚合操作方面。
上面的测试用的8万的数据量,不算大数据,不清楚在20、30万左右情况会怎么样。其实从架构设计层面来看,几万+几万的Join操作,随时需要避免;20、30万左右,对全表扫描、Order by、Group By需要高度重视;100万,上千万的数据量,基本上对Table的所有访问,都必须通过索引(对于SQL Server 2000中最好都是通过Clustered索引)来操作。基于这样一个前提,一般的普通的系统用MySQL数据库,在性能方面应该还是可以应付的。
作为一款开源的数据库,MySQL在性能的表现上还是比较优秀的,希望以后在不足的地方,MySQL能够不断完善,向商业数据库的性能靠近。至于数据库的监控、调试、调优等维护方面,以及其它一些开发方面的问题,就不多说了,忍一忍吧,也还是过得去了,毕竟是开源的,可以免费使用。
当然,从SQL Server的机制方面来看,性能问题基本都发生在需要大内存运算的地方,例如大数据量情况下的Order操作、Hash / Merge Join操作、Group By等聚合操作。大数据量情况下的Join本人是非常不赞同的,不管是业务层面架构设计层面还是程序实现层面,都应当尽一切可能避免。但Order、聚合操作等倒是经常需要用到,有兴趣时再测测聚合操作方面。
上面的测试用的8万的数据量,不算大数据,不清楚在20、30万左右情况会怎么样。其实从架构设计层面来看,几万+几万的Join操作,随时需要避免;20、30万左右,对全表扫描、Order by、Group By需要高度重视;100万,上千万的数据量,基本上对Table的所有访问,都必须通过索引(对于SQL Server 2000中最好都是通过Clustered索引)来操作。基于这样一个前提,一般的普通的系统用MySQL数据库,在性能方面应该还是可以应付的。
作为一款开源的数据库,MySQL在性能的表现上还是比较优秀的,希望以后在不足的地方,MySQL能够不断完善,向商业数据库的性能靠近。至于数据库的监控、调试、调优等维护方面,以及其它一些开发方面的问题,就不多说了,忍一忍吧,也还是过得去了,毕竟是开源的,可以免费使用。