mysql有大量可以修改的引數－－但不應該隨便去修改。通常只需要把基本的項配置正確（大部分情況下只有很少一些引數是真正重要的），應該將更多的時間花在schema的優化、索引，以及查詢設計上。在正確地配置了mysql的基本配置項之後，再花力氣去修改其它配置項的收益通常就比較小了。
1.建立mysql配置檔案
建議不要使用作業系統的安裝包自帶的配置檔案，最好從頭開始建立乙個配置檔案。（首先要確定mysql使用了哪個配置檔案！）
2.innodb緩衝池（buffer pool）
有乙個流行的經驗法則說，應該把緩衝池大小設定為伺服器記憶體的約75~80%，但並不總是正確的。有乙個更好的辦法來設定緩衝池大小，大致如下：
1、從伺服器記憶體總量開始
2、減去作業系統的記憶體占用
3、減去一些mysql自身需要的記憶體
4、減去足夠讓作業系統快取innodb日誌檔案的記憶體，至少是足夠快取最近經常訪問的部分。
5、減去其他配置的mysql緩衝和快取需要的記憶體，例如查詢快取，myisam鍵快取
6、除以105%，把結果向下取乙個合理的數值。
如果大部分都是innodb表，innodb緩衝池或許比其他任何東西更需要記憶體。innodb緩衝池並不僅僅快取索引：它還快取行的資料、自適應雜湊索引、插入快取（insert buffer）、鎖、以及其他內部資料結構。innodb還使用緩衝池來幫助延遲寫入，這樣就能合併多個寫入操作，然後一起順序地寫回。總之innodb嚴重依賴緩衝池，你必須確認為它分配了足夠的記憶體。
如果資料量不大，並且不會快速增長，就沒必要為緩衝池分配過多的記憶體。把緩衝池配置得比需要快取的表和索引還要大很多實際上沒有什麼意義。當然，對乙個迅速增長的資料庫做超前的規劃沒有問題，但有時我們也會看到乙個巨大的緩衝池只快取了一點點資料，這就沒有必要了。
很大的緩衝池也會帶一些挑戰，例如，預熱和關閉都會花費很長的時間。如果有很多髒頁在緩衝池裡，innodb關閉時可能會花費較長的時間把髒頁寫回資料檔案。當然也可以強制快速關閉，但是重啟時就必須做更多的恢復工作。
當髒頁的百分比超過了innodb_max_dirty_pages_pct閾值，innodb將快速地刷寫髒頁，嘗試讓髒頁的數量更低。當事務日誌沒有足夠的空間剩餘時，innodb將進入「激烈刷寫」模式，這就是大日誌可以提公升效能的乙個原因。
如果不能快速預熱，可以在重啟後立即進行全表掃瞄或者索引掃瞄，把索引載入緩衝池。也可以使用init_file設定，把sql放在乙個檔案裡，然後當mysql啟動的時候來執行。
3.執行緒快取
執行緒快取儲存那些當前沒有與連線關聯但是為後面新的連線服務的執行緒。當乙個新的連線建立時，如果快取中有執行緒存在，mysql從快取中刪除乙個執行緒，並且把它分配給這個新的連線。當連線關閉時，如果執行緒快取還有空間的話，mysql又會把執行緒放回快取。如果沒有空間的話，mysql會銷毀這個執行緒。只要mysql在快取裡還有空閒的執行緒，它就可以迅速地響應連線請求，因為這樣就不用為每個連線建立新的執行緒。
4.表快取
表快取可以重用資源。當乙個查詢請求訪問一張myisam表，mysql可以從快取的物件中獲取到檔案描述符，避免開啟乙個檔案描述符的開銷。對myisam表來說，表快取的真正好處是可以讓伺服器避免修改myisam檔案頭來標記表「正在使用中」，表快取對於innodb重要性就小得多，因為innodb不依賴它來做那麼多事，例如持有檔案描述符等。
5.innodb i/o配置（事務日誌）
innodb使用日誌來減少提交事務時的開銷。因為日誌中已經記錄了事務，就無須在每個事務提交時把緩衝池的髒塊重新整理(flush)到磁碟中。事務修改的資料和索引通常會對映到表空間的隨機位置，所以重新整理這些變更到磁碟需要很多隨機io。innodb假設使用常規磁碟，隨機io比順序io昂貴得多，因為乙個io請求需要時間把磁頭移到正確的位置，然後等待磁碟上讀出需要的部分，再轉到開始位置。
innodb用日誌把隨機io變成順序io。一旦日誌安全寫到磁碟，事務就持久化了，即使斷電了，innodb可以重放日誌並且恢復已經提交的事務。
innodb使用乙個後台執行緒智慧型地重新整理這些變更到資料檔案。這個執行緒可以批量組合寫入，使得資料寫入更順序，以提高效率。
整體的日誌檔案大小受控於innodb_log_file_size和innodb_log_files_in_group兩個引數，這對寫效能非常重要。日誌檔案的總大小是每個檔案的大小之和。
innodb使用多個檔案作為一組迴圈日誌。通常不需要修改預設的日誌數量，只修改每個日誌檔案的大小即可。要修改日誌檔案大小，需要完全關閉mysql，將舊的日誌檔案移到其他地方儲存，重新配置引數。
要確定理想的日誌檔案大小，必須權衡正常資料變更的開銷和崩潰恢復需要的時間，如果日誌太小，innodb必然將做更多的檢查點，導致更多的日誌寫。如果日誌太大，在崩潰恢復時innodb可能不得不做大量的工作。
當innodb變更任何資料時，會寫一條變更記錄到記憶體日誌緩衝區中。在緩衝滿的時候，事務提交的時候，或者每一秒鐘，這三個條件無論哪個先達到，innodb都會重新整理緩衝區的內容到磁碟日誌檔案。變數innodb_log_buffer_size可以控制日誌緩衝區的大小，預設為1m。通常不需要把日誌緩衝區設定得非常大。推薦的範圍是1~8m。作為乙個經驗法則，日誌檔案的全部大小，應該足夠容納伺服器乙個小時的活動內容。
innodb怎麼重新整理日誌緩衝？當innodb把日誌緩衝重新整理到磁碟日誌檔案時，會先使用乙個mutex鎖住緩衝區，重新整理到所需要的位置，然後移動剩下的條目到緩衝區的前面。日誌緩衝必須被重新整理到持久化儲存，以確保提交的事務完全被持久化了。如果和持久相比更在乎效能，可以修改innodb_flush_log_at_trx_commit變數來控制日誌緩衝重新整理的頻繁程度。可能的設定如下：
0：每秒一次把日誌緩衝寫到日誌檔案，但是事務提交時不做任何時。
1：將日誌緩衝寫到日誌檔案，然後每次事務提交都重新整理到持久化儲存（預設並且最安全的設定），該設定保證不會丟失任何已提交的事務。
2：每秒鐘做一次重新整理，但每次提交時把日誌緩衝寫到日誌檔案，但是不重新整理到持久化儲存。
「把日誌緩衝寫到日誌檔案」和「把日誌重新整理到持久化儲存」是不同的。在大部分作業系統中，把緩衝寫到日誌只是簡單地把資料從innodb的記憶體緩衝轉移到了作業系統的快取，也是在記憶體裡，並沒有真正把資料寫到持久化儲存。
如果mysql崩潰了或者斷電了，設定0和2通常會導致最多1秒的資料丟失，因為資料可能存在於作業系統的快取中。
相反，把日誌重新整理到持久化儲存意味著innodb請求作業系統把資料刷出快取，並且確認寫到磁碟了，這是乙個阻塞io的呼叫，直到資料被完全寫回才會完成，當寫資料到磁碟比較慢，而該配置項設定為1時，可能明顯地降低innodb每秒可以提交的事務數。
6.innodb併發配置
innodb有自己的「執行緒排程器」控制線程怎麼進入核心訪問資料，以及它們在核心中一次可以做哪些事。最基本的限制併發方式是使用innodb_thread_concurrency變數，它會限制一次性可以有多少執行緒進入核心，0表示不限制。
另外，也可以通過執行緒池(thread pool)來限制併發。
7.優化排序（filesorts）
如果查詢中所有需要的列和order by的列總大小超過max_length_for_sort_data位元組，則採用two-pass演算法，否則採用single-pass演算法。
8.其他配置項
1.max_connections：這個設定的作用就像乙個緊急剎車，以保證伺服器不會因應用程式激增的連線而不堪重負。如果應用程式有問題，或者伺服器遇到如連線延遲的問題，會建立很多新連線，但是如果不能執行查詢，那開啟乙個連線沒有好處，所以被「太多的連線」的錯誤拒絕是一種快速而代價小的失敗方式。
要時時小心可能遇到連線限制的突然襲擊。例如，若重啟應用伺服器，可能沒有把它的連線關閉乾淨，同時mysql可能沒有意識到它們已經被關閉了。當應用伺服器重新開始執行，並試圖開啟到資料庫的連線，就可能由於掛起的連線還沒有超時，導致新連線被拒絕。觀察max_used_connections狀態變數隨著時間的變化，如果這個值達到了max_connections，說明客戶端至少被拒絕了一次。
2.thread_cahce_size:觀察threads_connected狀態變數並且找到它在一般情況下的最大值和最小值。可以設定為波動範圍2~3倍大小。但是也不用設定得非常大，因為保持大量等待連線的空閒執行緒並沒有什麼真正的用處。
也可以觀察threads_created狀態隨時間的變化，如果這個值很大或者一直增長，這可能在告訴你，需要調大thread_cahce_size變數。檢視threads_cached來看有多少執行緒已經在快取中了。
另乙個相關的狀態變數是slow_launch_threads。這個狀態如果很大，那麼意味著某些情況延遲了連線分配新執行緒。一般來說可能是系統過載了，導致作業系統不能為新建立的執行緒排程cpu。
總之，如果使用的是innodb，最重要的配置項是以下兩個：innodb_buffer_pool_size和innodb_log_file_size
mysql重點：《高性
能mysql》讀書筆記－－索引：
高效能Mysql 伺服器效能剖析
1 如何確認伺服器是否達到了最佳效能狀態 2 找出某條sql語句為什麼不夠快 3 間歇性疑難故障 解決方案就是測量伺服器的時間花費在 使用的技術則是效能剖析 profiling 效能的定義是完成某個任務所花費的時間，資料庫的目的是執行sql語句。什麼是優化？降低cpu利用率？不是，資源是用來消耗並用...
高效能伺服器設計
原文 http blog.chinaunix.net u 5251 showart 236329.html 先後檢視了 haproxy l7sw 和lighttpd 的相關原始碼，無一例外，他們一致認為多路復用是效能最好的伺服器架構 事實也確實應該如此，程序的出現一方面就是為了儲存任務的執行上下文從...
高效能伺服器設計
先後檢視了haproxy l7sw 和lighttpd 的相關原始碼，無一例外，他們一致認為多路復用是效能最好的伺服器架構。事實也確實應該如此，程序的出現一方面就是為了儲存任務的執行上下文從而簡化應用程式設計，如果程式的邏輯結構不是很複雜，那麼用整個程序控制塊來儲存執行上下文未免有些大材小用，加上程...