[ MySQL ] MySQL vs SQL Server 2000 in Performance 5.0.24a

來源:互聯網
上載者:User
    拿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能夠不斷完善,向商務資料庫的效能靠近。至於資料庫的監控、調試、調優等維護方面,以及其它一些開發方面的問題,就不多說了,忍一忍吧,也還是過得去了,畢竟是開源的,可以免費使用。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.