MySQL性能調優技巧以及Monyog線程緩存監測

這篇文章主要介紹“MySQL性能調優技巧以及Monyog線程緩存監測”，在日常操作中，相信很多人在MySQL性能調優技巧以及Monyog線程緩存監測問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”MySQL性能調優技巧以及Monyog線程緩存監測”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

技巧#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：增加線程緩存大小

連接管理器線程處理服務器監聽的網絡接口上的客戶端連接請求。連接管理器線程將每個客戶端連接與專用于它的線程關聯，該線程負責處理該連接的身份驗證和所有請求處理。因此，線程和當前連接的客戶端之間是一對一的比例。確保線程緩存足夠大以容納所有傳入請求是非常重要的。

MySQL提供了許多與連接線程相關的服務器變量：

線程緩存大小由thread_cache_size系統變量決定。默認值為0（無緩存），這將導致為每個新連接設置一個線程，并在連接終止時需要處理該線程。如果希望服務器每秒接收數百個連接請求，那么應該將thread_cache_size設置的足夠高，以便大多數新連接可以使用緩存線程。可以在服務器啟動或運行時設置max_connections的值。

還應該監視緩存中的線程數（Threads_cached）以及創建了多少個線程，因為無法從緩存中獲取線程（Threads_created）。關于后者，如果Threads_created繼續以每分鐘多于幾個線程的增加，請考慮增加thread_cache_size的值。

使用MySQL show status命令顯示MySQL的變量和狀態信息。這里有幾個例子：

Monyog線程緩存監測

Monyog提供了一個監控線程緩存的屏幕，名為“線程”。與MySQL線程相關的服務器變量映射到以下Monyog指標：

• thread_cache_size：可以緩存的線程數。

• Threads_cached：緩存中的線程數。

• Threads_created：創建用于處理連接的線程。

Monyog線程屏幕還包括“線程緩存命中率”指標。這是一個提示線程緩存命中率的指標。如果值較低，則應該考慮增加線程緩存。在狀態欄以百分比形式顯示該值；它的值越接近100％越好。

如果這些指標的值等于或超過指定值，則可以將每一個指標配置為發出警告和/或嚴重警報。

其他相關的服務器變量

除了上述指標以外，還應該監控以下內容：

1. InnoDB緩沖池大小： InnoDB緩沖池大小在使用InnoDB的MySQL數據庫中起著至關重要的作用。緩沖池同時緩存數據和索引。它的值應該盡可能的大，以確保數據庫使用內存而不是硬盤驅動器進行讀取操作。

2. 臨時表大小： MySQL使用max_heap_table_size和tmp_table_size中較小的一個來限制內存中臨時表的大小。擁有較大的值可以幫助減少在磁盤上創建臨時表的數量，但也會增加服務器內存容量的風險，因為這個指標適用于每個客戶端。一般來說，32M到64M是建議的值，從這兩個變量開始并根據需要進行調優。

3. InnoDB日志緩沖區大小： MySQL每次寫入日志文件時，它都會利用可用于處理銷售數據的重要系統資源。因此，將InnoDB日志緩沖區大小設置為較大值才有意義。這樣，服務器在大型事務中寫入磁盤的次數就減少了，從而最大限度地減少了這些耗時的操作。64M是這個變量的一個很好的起點。

到此，關于“MySQL性能調優技巧以及Monyog線程緩存監測”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！