先說一下最常見基本的系統(tǒng)瓶頸：

1、硬盤搜索?，F(xiàn)代磁盤的平均時(shí)間通常小于10ms，因此理論上我們每秒能夠大約搜索1000次，這樣我們在這樣一個(gè)磁盤上搜索一個(gè)數(shù)據(jù)，很難優(yōu)化，一個(gè)辦法就是將數(shù)據(jù)分布在多個(gè)磁盤。
2、IO讀寫。就磁盤來講，一般傳輸10-20Mb/s，同樣的，優(yōu)化可以從多個(gè)磁盤并行讀寫。
3、CPU周期。我們將數(shù)據(jù)讀入內(nèi)存后，需要對它進(jìn)行處理并獲取我們需要的結(jié)果。表相對于內(nèi)存較小時(shí)常見的限制因素。但是對于小表，速度通常不成問題。
4、內(nèi)存帶寬。當(dāng)CPU需要的數(shù)據(jù)超出CPU緩存，主緩存帶寬就成為內(nèi)存的一個(gè)瓶頸。

再說一下mysql設(shè)計(jì)上邊的瓶頸：（本人了解一下它的數(shù)據(jù)庫引擎，wiki上邊說的一些缺陷）
MyISAM是MySQL的默認(rèn)數(shù)據(jù)庫引擎 (5.5版之前)，由早期的ISAM所改良。雖然性能極佳，但卻有一個(gè)缺點(diǎn)：不支持code error!（transaction）。不過，在這幾年的發(fā)展下，MySQL也導(dǎo)入了InnoDB (另一種數(shù)據(jù)庫引擎)，以強(qiáng)化code error!與并發(fā)違規(guī)處理機(jī)制，后來就逐漸取代MyISAM。
每個(gè)MyISAM數(shù)據(jù)表，皆由存儲在硬盤上的3個(gè)文件所組成，每個(gè)文件都以數(shù)據(jù)表名稱為主文件名，并搭配不同擴(kuò)展名區(qū)分文件類型：
.frm－－存儲數(shù)據(jù)表定義，此文件非MyISAM引擎的一部份。
.MYD－－存放真正的數(shù)據(jù)。
.MYI－－存儲索引信息。

1、InnoDB可借由交易記錄檔 (Transaction Log) 來恢復(fù)程序崩潰 (crash)，或非預(yù)期退出所造成的數(shù)據(jù)錯(cuò)誤；而MyISAM遇到錯(cuò)誤，必須完整掃描后才能重建索引，或修正未寫入硬盤的錯(cuò)誤。InnoDB的修復(fù)時(shí)間，大略都是固定的，但MyISAM的修復(fù)時(shí)間，則與數(shù)據(jù)量的多寡成正比。相對而言，隨著數(shù)據(jù)量的增加，InnoDB會有較佳的穩(wěn)定性。
2、MyISAM必須依靠操作系統(tǒng)來管理讀取與寫入的高速緩存，而InnoDB則是有自己的讀寫高速緩存管理機(jī)制。(InnoDB不會將被修改的code error!立即交給操作系統(tǒng)) 因此在某些情況下，InnoDB的數(shù)據(jù)訪問會比MyISAM更有效率。
3、InnoDB目前并不支持MyISAM所提供的壓縮與 terse row formats，所以對硬盤與高速緩存的使用量較大。因此MySQL從5.0版開始，提供另一個(gè)負(fù)載較輕的格式，他可減少約略 20% 的系統(tǒng)負(fù)載，而壓縮功能已計(jì)劃于未來的新版中推出。
4、當(dāng)操作完全兼容ACID (code error!) 時(shí)，雖然InnoDB會自動(dòng)合并數(shù)筆連接，但每次有code error!產(chǎn)生時(shí)，仍至少須寫入硬盤一次，因此對于某些硬盤或磁盤陣列，會造成每秒200次的code error!處理上限。若希望達(dá)到更高的性能且保持code error!的完整性，就必使用軟盤高速緩存與電池備援。當(dāng)然 InnoDB 也提供數(shù)種對性能沖擊較低的模式，但相對的也會降低code error!的完整性。而MyISAM則無此問題，但這并非因?yàn)樗容^先進(jìn)，這只是因?yàn)樗恢С謈ode error!。

（InnoDB，是MySQL的數(shù)據(jù)庫引擎之一，為MySQL AB發(fā)行binary的標(biāo)準(zhǔn)之一。InnoDB由Innobase Oy公司所開發(fā)，2006年五月時(shí)由甲骨文公司并購。與傳統(tǒng)的ISAM與MyISAM相比，InnoDB的最大特色就是支持了ACID兼容的事務(wù)（Transaction）功能，類似于PostgreSQL。）