關於MYSQL的最佳化全面詳解_Mysql

先說一下最常見基本的系統瓶頸：

1、硬碟搜尋。現代磁碟的平均時間通常小於10ms，因此理論上我們每秒能夠大約搜尋1000次，這樣我們在這樣一個磁碟上搜尋一個資料，很難最佳化，一個辦法就是將資料分布在多個磁碟。
2、IO讀寫。就磁碟來講，一般傳輸10-20Mb/s，同樣的，最佳化可以從多個磁碟並行讀寫。
3、CPU周期。我們將資料讀入記憶體後，需要對它進行處理並擷取我們需要的結果。表相對於記憶體較小時常見的限制因素。但是對於小表，速度通常不成問題。
4、記憶體頻寬。當CPU需要的資料超出CPU緩衝，主緩衝頻寬就成為記憶體的一個瓶頸。

再說一下mysql設計上邊的瓶頸：（本人瞭解一下它的資料庫引擎，wiki上邊說的一些缺陷）
MyISAM是MySQL的預設資料庫引擎 (5.5版之前)，由早期的ISAM所改良。雖然效能極佳，但卻有一個缺點：不支援code error!（transaction）。不過，在這幾年的發展下，MySQL也匯入了InnoDB (另一種資料庫引擎)，以強化code error!與並發違規處理機制，後來就逐漸取代MyISAM。
每個MyISAM資料表，皆由儲存在硬碟上的3個檔案所組成，每個檔案都以資料表名稱為主檔案名，並搭配不同副檔名區分檔案類型：
.frm－－儲存資料表定義，此檔案非MyISAM引擎的一部份。
.MYD－－存放真正的資料。
.MYI－－儲存索引資訊。

1、InnoDB可藉由交易記錄檔 (Transaction Log) 來恢複程式崩潰 (crash)，或非預期退出所造成的資料錯誤；而MyISAM遇到錯誤，必須完整掃描後才能重建索引，或修正未寫入硬碟的錯誤。InnoDB的修複時間，大略都是固定的，但MyISAM的修複時間，則與資料量的多寡成正比。相對而言，隨著資料量的增加，InnoDB會有較佳的穩定性。
2、MyISAM必須依靠作業系統來管理讀取與寫入的快取，而InnoDB則是有自己的讀寫快取管理機制。(InnoDB不會將被修改的code error!立即交給作業系統) 因此在某些情況下，InnoDB的資料訪問會比MyISAM更有效率。
3、InnoDB目前並不支援MyISAM所提供的壓縮與 terse row formats，所以對硬碟與快取的使用量較大。因此MySQL從5.0版開始，提供另一個負載較輕的格式，他可減少約略 20% 的系統負載，而壓縮功能已計劃於未來的新版中推出。
4、當操作完全相容ACID (code error!) 時，雖然InnoDB會自動合并數筆串連，但每次有code error!產生時，仍至少須寫入硬碟一次，因此對於某些硬碟或磁碟陣列，會造成每秒200次的code error!處理上限。若希望達到更高的效能且保持code error!的完整性，就必使用磁碟片快取與電池備援。當然 InnoDB 也提供數種對效能衝擊較低的模式，但相對的也會降低code error!的完整性。而MyISAM則無此問題，但這並非因為它比較先進，這隻是因為它不支援code error!。

（InnoDB，是MySQL的資料庫引擎之一，為MySQL AB發行binary的標準之一。InnoDB由Innobase Oy公司所開發，2006年五月時由甲骨文公司併購。與傳統的ISAM與MyISAM相比，InnoDB的最大特色就是支援了ACID相容的事務（Transaction）功能，類似於PostgreSQL。）