[ 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）。   

	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能够不断完善，向商业数据库的性能靠近。至于数据库的监控、调试、调优等维护方面，以及其它一些开发方面的问题，就不多说了，忍一忍吧，也还是过得去了，毕竟是开源的，可以免费使用。