技巧#1：確定mysql的最大連線數
對於mysql的最大連線數，一次最好是傳送5個請求到web伺服器。對web伺服器的5個請求中的一部分將用於css樣式表，影象和指令碼等資源。由於諸如瀏覽器快取等原因，要獲得準確的mysql到web伺服器的請求比率可能很困難; 要想得到乙個確切的數字，就需要分析web伺服器的日誌檔案。例如，可以手動訪問apache的「access_log」日誌檔案，也可以通過analog或webalizer等實用程式訪問日誌檔案。
一旦有了對特定使用情況的準確估計，請將該比率乘以web伺服器的最大連線數。例如，如果web伺服器配置為最多為256個客戶端提供服務，mysql請求與web請求的比率為1/8，則最好將最大資料庫連線數設定為32。還要考慮留有安全餘量，把這個數乘以2，得到最終的數量。只有在基礎設施支援的情況下，才能嘗試將資料庫連線數的最大數量與web伺服器的客戶端限制相匹配。在大多數情況下，最好保持接近32。
在monyog中檢視mysql連線
在mysql資料庫中，mysql的最大併發連線數是儲存在全域性變數max_connections中的。monyog報告變數「max_connections」作為當前連線監控組中的「最大允許」指標。它還將該數字除以開啟的連線數，以生成連線使用百分比：
還有乙個連線歷史記錄監控，可以幫助計算最佳的最大併發連線數。它包括嘗試，拒絕和成功連線的數量。此外，允許達到的最大指標的百分比顯示為乙個進度條，可以讓你快速評估伺服器在過去達到的最大併發連線數：
技巧#2：為臨時表分配足夠的記憶體
在某些情況下，伺服器在處理語句時會建立內部臨時表。臨時表用於內部操作如group by和distinct，還有一些order by查詢以及union和from子句（派生表）中的子查詢。這些都是在記憶體中建立的記憶體表。記憶體中臨時表的最大大小由tmp_table_size和max_heap_table_size中較小的值確定。如果臨時表的大小超過這個閾值，則將其轉換為磁碟上的innodb或myisam表。此外，如果查詢涉及blob或text列，而這些列不能儲存在記憶體表中，臨時表總是直接指向磁碟。
這種轉換的代價很大，所以考慮增加max_heap_table_size和tmp_table_size變數的大小來幫助減少在磁碟上建立臨時表的數量。請記住，這將需要大量記憶體，因為記憶體中臨時表的大小是基於「最壞情況」的。例如，記憶體表總是使用固定長度的列，所以字元列使用varchar（255）。這可以使記憶體中的臨時錶比想象的要大得多—事實上，這比查詢表的總大小要大很多倍！當增加max_heap_table_size和tmp_table_sizevariables的大小時，一定要監視伺服器的記憶體使用情況，因為記憶體中的臨時表可能會增加達到伺服器記憶體容量的風險。
一般來說，32m到64m是建議值，從這兩個變數開始並根據需要進行調優。
在monyog中的臨時表監測
臨時表的監測是許多預定義的monyog監測之一。它提供了一些臨時表使用的指標，包括：
允許的最大值：顯示tmp_table_size伺服器變數的值，它定義了在記憶體中建立的臨時表的最大大小。與max_heap_table_size一起，這個值定義了可以在記憶體中建立的臨時表的最大大小。如果記憶體臨時表大於此大小，則將其儲存在磁碟上。
記憶體表的最大大小：顯示max_heap_table_size伺服器變數的值，該值定義了顯式建立的memory儲存引擎表的最大大小。
建立的臨時表總數：顯示created_tmp_tables伺服器變數的值，它定義了在記憶體中建立的臨時表的數量。
在磁碟上建立的臨時表：顯示created_tmp_disk_tables伺服器變數的值，該變數定義了在磁碟上建立的臨時表的數量。如果這個值很高，則應該考慮增加tmp_table_size和max_heap_table_size的值，以便增加建立記憶體臨時表的數量，從而減少在磁碟上建立臨時表的數量。
磁碟：總比率：基於created_tmp_disk_tables除以created_tmp_tables的計算值。由於tmp_table_size或max_heap_table_size不足而在磁碟上建立的臨時表的百分比。monyog將這個數字顯示為乙個進度條和百分比，以便快速確定有多少磁碟用於臨時表，而不是記憶體。
趨勢圖可用於建立的總表，磁碟上建立的表和磁碟的總比值。這些讓我們看到了它們隨著時間的演變：
技巧#3：增加執行緒快取大小
連線管理器執行緒處理伺服器監聽的網路介面上的客戶端連線請求。連線管理器執行緒將每個客戶端連線與專用於它的執行緒關聯，該執行緒負責處理該連線的身份驗證和所有請求處理。因此，執行緒和當前連線的客戶端之間是一對一的比例。確保執行緒快取足夠大以容納所有傳入請求是非常重要的。
執行緒快取大小由thread_cache_size系統變數決定。預設值為0（無快取），這將導致為每個新連線設定乙個執行緒，並在連線終止時需要處理該執行緒。如果希望伺服器每秒接收數百個連線請求，那麼應該將thread_cache_size設定的足夠高，以便大多數新連線可以使用快取執行緒。可以在伺服器啟動或執行時設定max_connections的值。
還應該監視快取中的執行緒數（threads_cached）以及建立了多少個執行緒，因為無法從快取中獲取執行緒（threads_created）。關於後者，如果threads_created繼續以每分鐘多於幾個執行緒的增加，請考慮增加thread_cache_size的值。
使用mysql show status命令顯示mysql的變數和狀態資訊。這裡有幾個例子：
mysql 效能調優技巧
monyog執行緒快取監測
thread_cache_size：可以快取的執行緒數。
threads_cached：快取中的執行緒數。
threads_created：建立用於處理連線的執行緒。
monyog執行緒螢幕還包括「執行緒快取命中率」指標。這是乙個提示執行緒快取命中率的指標。如果值較低，則應該考慮增加執行緒快取。在狀態列以百分比形式顯示該值；它的值越接近100％越好。
如果這些指標的值等於或超過指定值，則可以將每乙個指標配置為發出警告和/或嚴重警報。
其他相關的伺服器變數
除了上述指標以外，還應該監控以下內容：
innodb緩衝池大小： innodb緩衝池大小在使用innodb的mysql資料庫中起著至關重要的作用。緩衝池同時快取資料和索引。它的值應該盡可能的大，以確保資料庫使用記憶體而不是硬碟驅動器進行讀取操作。
臨時表大小： mysql使用max_heap_table_size和tmp_table_size中較小的乙個來限制記憶體中臨時表的大小。擁有較大的值可以幫助減少在磁碟上建立臨時表的數量，但也會增加伺服器記憶體容量的風險，因為這個指標適用於每個客戶端。一般來說，32m到64m是建議的值，從這兩個變數開始並根據需要進行調優。
innodb日誌緩衝區大小： mysql每次寫入日誌檔案時，它都會利用可用於處理銷售資料的重要系統資源。因此，將innodb日誌緩衝區大小設定為較大值才有意義。這樣，伺服器在大型事務中寫入磁碟的次數就減少了，從而最大限度地減少了這些耗時的操作。64m是這個變數的乙個很好的起點。
結論雖然即便是最大的公司**也會因宕機而遭受損失，但這種影響對於處理網上銷售的中小型企業尤其關鍵。根據最近的乙份調查報告顯示，一分鐘的宕機導致企業平均損失約5000美元。不要讓你的業務成為那種統計資料（因為宕機造成的損失）的一部分。在假日繁忙之前，主動調優mysql資料庫伺服器（s）並收穫回報吧！
www.yisuping.com
MySQL效能調優技巧
原文 mysql performance tuning tips for the shopping season 翻譯 無阻我飛揚 摘要 針對購物旺季 流量會對資料庫造成的壓力，作者給出了mysql效能調優的一些技巧，這些技巧極具參考價值，通過這些調優，可以有效避免因為流量過大造成伺服器宕機，從而給...
MySQL效能調優技巧
摘要 針對購物旺季 流量會對資料庫造成的壓力，作者給出了mysql效能調優的一些技巧，這些技巧極具參考價值，通過這些調優，可以有效避免因為流量過大造成伺服器宕機，從而給企業造成經濟損失。以下是譯文 萬聖節已經過去很久了，該是把注意力集中在即將到來的假日季節的時候了。首先是感恩節，接著就是黑色星期五和...
MySQL效能調優技巧
原文 原文 mysql performance tuning tips for the shopping season 翻譯 無阻我飛揚 摘要 針對購物旺季 流量會對資料庫造成的壓力，作者給出了mysql效能調優的一些技巧，這些技巧極具參考價值，通過這些調優，可以有效避免因為流量過大造成伺服器宕機，...