10 從MySQL得到最大的性能
優化是一項復雜的任務，因為它最終需要對整個系統的理解。當用你的系統/應用的小知識做一些局部優化是可能的時候，你越想讓你的系統更優化，你必須知道它也越多。
因此，本章將試圖解釋並給出優化MySQL的不同方法的一些例子。但是記住總是有某些(逐漸變難)是系統更快的方法留著去做。
10.1 優化概述
為了使一個系統更快的最重要部分當然是基本設計。你也需要知道你的系統將做這樣的事情，那就是你的瓶頸。
最常見的瓶頸是：
* 磁盤尋道。磁盤花時間找到一個數據，用在1999年的現代磁盤其平均時間通常小於10ms，因此理論上我們能大約一秒尋道 1000 次。這個時間用新磁盤提高很慢並且很難對一個表優化。優化它的方法是將數據散布在多個磁盤上。
* 當磁盤在我們需要讀數據的正確位置時，磁盤讀/寫。用1999年的現代，一個磁盤傳輸類似10-20Mb/s。這必尋道更容易優化，因為你能從多個磁盤並行地讀。
* CPU周期。當我們讀數據進內存時，(或如果它已經在那裡)我們需要處理它以達到我們的結果。當我們有相對內存較小的表時，這是最常見的限制因素，但是用小表速度通常不是問題。
* 內存帶寬。當CPU需要超出適合cpu緩存的數據時，緩存帶寬就成為內存的一個瓶頸。這是對大多數系統的一個不常見的瓶頸但是你應該知道它。
10.2 系統/編譯時和啟動參數的調節
我們以系統級的東西開始，因為這些決策的某一些很早就做好了。在其他情況下，快速浏覽這部分可能就夠了，因為它對大收獲並不重要，但是有一個關於在這個層次上收獲有多大的感覺總是好的。
使用的缺省OS確實重要！為了最大程度地使用多CPU，應該使用Solaris(因為線程工作得確實不錯)或Linux(因為2.2本的核心又確實不錯的SMP支持)。而且在32位的機器上，Linux缺省有2G的文件大小限制。當新的文件系統被釋出時( XFS )，希望這不久被修正。
因為我們沒在很多平台上運行生產MySQL，我們忠告你在可能選擇它前，測試你打算運行的平台。
其他建議：
* 如果你有足夠的RAM，你能刪除所有交換設備。一些操作系統在某些情況下將使用一個SWAP設備，即使你有空閒的內存。
* 使用--skip-locking的MySQL選項避免外部鎖定。注意這將不影響MySQL功能，只要它僅運行在一個服務器上。只要在你運行myisamchk以前，記得要停掉服務器(或鎖定相關部分)。在一些系統上這個開關是強制的，因為外部鎖定不是在任何情況下都工作。當用MIT-pthreads編譯時，--skip-locking選項缺省為打開(on)，因為flock()沒在所有的平台上被MIT-pthreads充分支持。唯一的情況是如果你對同一數據運行MySQL服務器(不是客戶)，你不能使用--skip-locking之時，否則對沒有先清掉(flushing)或先鎖定MySQLd服務器的表上運行myisamchk。你仍然能使用LOCK TABLES/ UNLOCK TABLES，即使你正在使用--skip-locking。
10.2.1 編譯和鏈接怎樣影響MySQL的速度
大多數下列測試在Linux上並用MySQL基准進行的，但是它們應該對其他操作系統和工作負載給出一些指示。
當你用-static鏈接時，你得到最快的可執行文件。使用Unix套接字而非TCP/IP連接一個數據庫也可給出好一些的性能。
在Linux上，當用pgcc和-O6編譯時，你將得到最快的代碼。為了用這些選項編譯“sql_yacc.cc”，你需要大約200M內存，因為gcc/pgcc需要很多內存使所有函數嵌入（inline）。在配置MySQL時，你也應該設定CXX=gcc以避免包括libstdc++庫(它不需要)。
只通過使用一個較好的編譯器或較好的編譯器選項，在應用中你能得到一個10-30%的加速。如果你自己編譯SQL服務器，這特別重要！
在Intel上，你應該例如使用pgcc或Cygnus CodeFusion編譯器得到最大速度。我們已經測試了新的 Fujitsu編譯器，但是它是還沒足夠不出錯來優化編譯MySQL。
這裡是我們做過的一些測量表：
