MySQL數據庫服務器優化詳細

最近在網上查了一些有關優化MySql的資料，並對照MySql手冊對一些調優設置進行了細結，可是因爲時間比較勿忙，沒來得及對這些設置進行實驗/測試，你能夠把這些方法應用到實際中，得出具體結論。

調優方法大體以下：

MySql服務器的後臺管理程序，要想使用客戶端程序，該程序必須運行，由於客戶端經過鏈接服務器來訪問數據庫。下面讓咱們以服務器的系統變量和狀態變量爲根據，優化咱們的MySql數據庫服務。在這以前，咱們須要掌握如下方法：

查看MySql狀態及變量的方法：

Mysql> show status ——顯示狀態信息（擴展show status like 'XXX'）

Mysql> show variables ——顯示系統變量（擴展show variables like 'XXX'）

Mysql> show innodb status ——顯示InnoDB存儲引擎的狀態

Shell> mysqladmin variables -u username -p password——顯示系統變量

Shell> mysqladmin extended-status -u username -p password——顯示狀態信息

 

查看狀態變量及幫助：

Shell> mysqld --verbose --help [|more #逐行顯示]

 

首先，讓咱們看看有關請求鏈接的變量：

爲了能適應更多數據庫應用用戶，MySql提供了鏈接（客戶端）變量，以對不一樣性質的用戶羣體提供不一樣的解決方案，筆者就max_connections，back_log 作了一些細結，以下：

max_connections 是指MySql的最大鏈接數，若是服務器的併發鏈接請求量比較大，建議調高此值，以增長並行鏈接數量，固然這創建在機器能支撐的狀況下，由於若是鏈接數越 多，介於MySql會爲每一個鏈接提供鏈接緩衝區，就會開銷越多的內存，因此要適當調整該值，不能盲目提升設值。能夠過'conn%'通配符查看當前狀態的 鏈接數量，以定奪該值的大小。

back_log 是要求MySQL能有的鏈接數量。當主要MySQL線程在一個很短期內獲得很是多的鏈接請求，這就起做用，而後主線程花些時間(儘管很短)檢查鏈接而且 啓動一個新線程。back_log值指出在MySQL暫時中止回答新請求以前的短期內多少個請求能夠被存在堆棧中。若是指望在一個短期內有不少鏈接， 你須要增長它。也就是說，若是MySql的鏈接數據達到max_connections時，新來的請求將會被存在堆棧中，以等待某一鏈接釋放資源，該堆棧 的數量即back_log，若是等待鏈接的數量超過back_log，將不被授予鏈接資源。另外，這值（back_log）限於您的操做系統對到來的 TCP/IP鏈接的偵聽隊列的大小。你的操做系統在這個隊列大小上有它本身的限制（能夠檢查你的OS文檔找出這個變量的最大值），試圖設定 back_log高於你的操做系統的限制將是無效的。

優化了MySql的鏈接後屬性後，咱們須要看看緩衝區變量：

使用MySql數據庫存儲大量數據（或使用複雜查詢）時，咱們應該考慮MySql的內存配置。若是配置MySQL服務器使用太少的內存會致使性 能不是最優的；若是配置了太多的內存則會致使崩潰，沒法執行查詢或者致使交換操做嚴重變慢。在如今的32位平臺下，仍有可能把全部的地址空間都用完，所以 須要審視。

計算內存使用的祕訣公式就能相對地解決這一部分問題。不過，現在這個公式已經很複雜了，更重要的是，經過它計算獲得的值只是「理論可能」並非 真正消耗的值。事實上，有8GB內存的常規服務器常常能運行到最大的理論值（100GB甚至更高）。此外，你輕易不會使用到「超額因素」（它實際上依賴於 應用以及配置）。一些應用可能須要理論內存的10%而有些僅需1%。

那麼，咱們能夠作什麼呢？

 

來看看那些在啓動時就須要分配而且老是存在的全局緩衝吧！

 

全局緩衝：

key_buffer_size, innodb_buffer_pool_size, innodb_additional_mem_pool_size，innodb_log_buffer_size, query_cache_size

 

注：若是你大量地使用MyISAM表，那麼你也能夠增長操做系統的緩存空間使得MySQL也能用得着。把這些也都加到操做系統和應用程序所需的 內存值之中，可能須要增長32MB甚至更多的內存給MySQL服務器代碼以及各類不一樣的小靜態緩衝。這些就是你須要考慮的在MySQL服務器啓動時所需的 內存。其餘剩下的內存用於鏈接。

 

key_buffer_size 決定索引處理的速度，尤爲是索引讀的速度。通常咱們設爲16M，經過檢查狀態值Key_read_requests和Key_reads，能夠知道 key_buffer_size設置是否合理。比例key_reads / key_read_requests應該儘量的低，至少是1:100，1:1000更好（上述狀態值可使用'key_read%'得到用來顯示狀態數 據）。key_buffer_size只對MyISAM表起做用。即便你不使用MyISAM表，可是內部的臨時磁盤表是MyISAM表，也要使用該值。可 以使用檢查狀態值'created_tmp_disk_tables'得知詳情。

 

innodb_buffer_pool_size 對於InnoDB表來講，做用就至關於key_buffer_size對於MyISAM表的做用同樣。InnoDB使用該參數指定大小的內存來緩衝數據和 索引。對於單獨的MySQL數據庫服務器，最大能夠把該值設置成物理內存的80%。

 

innodb_additional_mem_pool_size 指定InnoDB用來存儲數據字典和其餘內部數據結構的內存池大小。缺省值是1M。一般不用太大，只要夠用就行，應該與表結構的複雜度有關係。若是不夠用，MySQL會在錯誤日誌中寫入一條警告信息。

 

innodb_log_buffer_size 指定InnoDB用來存儲日誌數據的緩存大小，若是您的表操做中包含大量併發事務（或大規模事務），而且在事務提交前要求記錄日誌文件，請儘可能調高此項值，以提升日誌效率。

 

query_cache_size 是MySql的查詢緩衝大小。（從4.0.1開始，MySQL提供了查詢緩衝機制）使用查詢緩衝，MySQL將SELECT語句和查詢結果存放在緩衝區 中，從此對於一樣的SELECT語句（區分大小寫），將直接從緩衝區中讀取結果。根據MySQL用戶手冊，使用查詢緩衝最多能夠達到238%的效率。經過 檢查狀態值’Qcache_%’，能夠知道query_cache_size設置是否合理：若是Qcache_lowmem_prunes的值很是大，則 代表常常出現緩衝不夠的狀況，若是Qcache_hits的值也很是大，則代表查詢緩衝使用很是頻繁，此時須要增長緩衝大小；若是Qcache_hits 的值不大，則代表你的查詢重複率很低，這種狀況下使用查詢緩衝反而會影響效率，那麼能夠考慮不用查詢緩衝。此外，在SELECT語句中加入 SQL_NO_CACHE能夠明確表示不使用查詢緩衝。

 

除了全局緩衝，MySql還會爲每一個鏈接發放鏈接緩衝。

 

鏈接緩衝：

每一個鏈接到MySQL服務器的線程都須要有本身的緩衝。大概須要馬上分配256K，甚至在線程空閒時，它們使用默認的線程堆棧，網絡緩存等。事 務開始以後，則須要增長更多的空間。運行較小的查詢可能僅給指定的線程增長少許的內存消耗，然而若是對數據表作複雜的操做例如掃描、排序或者須要臨時表， 則需分配大約 read_buffer_size，sort_buffer_size，read_rnd_buffer_size，tmp_table_size 大小的內存空間。不過它們只是在須要的時候才分配，而且在那些操做作完以後就釋放了。有的是馬上分配成單獨的組塊。tmp_table_size 可能高達MySQL所能分配給這個操做的最大內存空間了。注意，這裏須要考慮的不僅有一點 —— 可能會分配多個同一種類型的緩存，例如用來處理子查詢。一些特殊的查詢的內存使用量可能更大——若是在MyISAM表上作成批的插入時須要分配 bulk_insert_buffer_size 大小的內存；執行 ALTER TABLE， OPTIMIZE TABLE， REPAIR TABLE 命令時須要分配 myisam_sort_buffer_size 大小的內存。

 

read_buffer_size 是MySql讀入緩衝區大小。對錶進行順序掃描的請求將分配一個讀入緩衝區，MySql會爲它分配一段內存緩衝區。read_buffer_size變量 控制這一緩衝區的大小。若是對錶的順序掃描請求很是頻繁，而且你認爲頻繁掃描進行得太慢，能夠經過增長該變量值以及內存緩衝區大小提升其性能。

 

sort_buffer_size 是MySql執行排序使用的緩衝大小。若是想要增長ORDER BY的速度，首先看是否可讓MySQL使用索引而不是額外的排序階段。若是不能，能夠嘗試增長sort_buffer_size變量的大小。

 

read_rnd_buffer_size 是MySql的隨機讀緩衝區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩 衝，以免磁盤搜索，提升查詢速度，若是須要排序大量數據，可適當調高該值。但MySql會爲每一個客戶鏈接發放該緩衝空間，因此應儘可能適當設置該值，以避 免內存開銷過大。

 

tmp_table_size是MySql的heap （堆積）表緩衝大小。全部聯合在一個DML指令內完成，而且大多數聯合甚至能夠不用臨時表便可以完成。大多數臨時表是基於內存的(HEAP)表。具備大的 記錄長度的臨時表 (全部列的長度的和)或包含BLOB列的表存儲在硬盤上。若是某個內部heap（堆積）表大小超過tmp_table_size，MySQL能夠根據須要 自動將內存中的heap表改成基於硬盤的MyISAM表。還能夠經過設置tmp_table_size選項來增長臨時表的大小。也就是說，若是調高該 值，MySql同時將增長heap表的大小，可達到提升聯接查詢速度的效果。

 

當咱們設置好了緩衝區大小以後，再來看看：

 

table_cache 全部線程打開的表的數目，增大該值能夠增長mysqld須要的文件描述符的數量。每當MySQL訪問一個表時，若是在表緩衝區中還有空間，該表就被打開並 放入其中，這樣能夠更快地訪問表內容。經過檢查峯值時間的狀態值’Open_tables’和’Opened_tables’，能夠決定是否須要增長 table_cache的值。若是你發現open_tables等於table_cache，而且opened_tables在不斷增加，那麼你就須要增 加table_cache的值了（上述狀態值可使用’Open%tables’得到）。注意，不能盲目地把table_cache設置成很大的值。若是 設置得過高，可能會形成文件描述符不足，從而形成性能不穩定或者鏈接失敗。

 

作了以上方面的調優設置以後，MySql應該基本能知足您需求（固然是創建在調優設置適當的狀況下），咱們還應該瞭解並注意：

 

只有簡單查詢OLTP（聯機事務處理）應用的內存消耗常常是使用默認緩衝的每一個線程小於1MB，除非須要使用複雜的查詢不然無需增長每一個線程的 緩衝大小。使用1MB的緩衝來對10行記錄進行排序和用16MB的緩衝基本是同樣快的（實際上16MB可能會更慢，不過這是其餘方面的事了）。

 

找出MySQL服務器內存消耗的峯值。這很容易就能計算出操做系統所需的內存、文件緩存以及其餘應用。在32位環境下，還須要考慮到32位的限 制，限制 「mysqld」 的值大約爲2.5G（實際上還要考慮到不少其餘因素）。如今運行 「ps aux」 命令來查看 「VSZ」 的值（MySQL 進程分配的虛擬內存）。監視着內存變化的值，就能知道是須要增長或減小當前的內存值了。

 

最後來看看調優設置方法：

 

安裝好MySql後，配製文件應該在 ./share/mysql ("./"即MySql安裝目錄) 目錄中，配製文件有幾個，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf。win環境下即存在於MySql安裝目錄中的.ini文件。不一樣的流量的網站和不一樣配製的服務器環境，固然須要有不一樣的配製文 件了。

通常的狀況下，my-medium.cnf這個配製文件就能知足咱們的大多須要；通常咱們會把配置文件拷貝到 /etc/my.cnf ，win環境下則拷備到 my.ini 下便可，只須要修改這個配置文件就能夠了。