MySQL優化思路，以及解決方案

             mysql優化索引和配置，以及慢查詢分析

s首先基本的思路

1）性能瓶頸定位

使用show命令、

慢查詢日誌、

explain分析查詢、

profiling分析查詢、

2）索引及查詢優化

3）配置優化

MySQL數據庫常見的兩個瓶頸cpu、i/o：

CPU主要在飽和的時候發生在數據裝入內存或磁盤上讀取數據的時候

i/o發生在裝入數據遠大於內存容量的時候，若是應用分佈在網絡上，那麼查詢量至關大的網絡瓶頸，咱們能夠經過mpstat、iostat、vmstat、sar等命令查看系統的性能狀態

例如：mpstat  3  3 {表示每3秒輸出三次}

 

另外除了服務器硬件的性能瓶頸，對於mysql系統自己，咱們可使用工具來優化數據庫的性能；一般有三種：

使用索引、   使用explain分析查詢、   調整mysql的內部配置

 

1：查詢與索引優化分析；

在優化mysql時，一般須要對數據庫進行分析，常見的分析有慢查詢日誌，explain分析查詢，profiling分析以及show命令查詢系統狀態及系統變量。

 

show命令

能夠經過show命令查看mysql狀態以及變量，找到系統的瓶頸；

查看mysql服務器配置信息 、

 

查看mysql服務器運行的各類狀態、

 

顯示系統變量：=====>> mysqladmin variables -u username -ppassword

顯示系統狀態：======>> mysqladmin exlended -stautus -u username -ppassword

另外能夠經過：

 

慢查詢日誌

 

開啓慢查詢日誌；在配置文件中/etc/my.cnf中添加三個參數；

slow_query_log=1 [1表示開啓、0表示關閉]

slow_query_log_file=/usr/local/mysql/data/slow-query.log 慢查旬日誌存放位置

long-query_time=1 表示查詢超過1秒的時間記錄

在my.cnf中添加log-queries-not-using-indexes參數，表示向慢查詢日誌中記錄下沒有使用索引的查詢

慢查詢日誌也能夠在命令行中開啓：

 

只不過在命令行中的屬於臨時生效，而在主配置文件中屬於永久生效

查看慢查詢的設置信息：

 

查看超時的時間限制

 

另外咱們還能夠同過查看慢查詢日誌查看執行效率低的sql語句

 

能夠看到剛纔指定慢查詢文件的路徑這條命令的執行結果時間超過了0.01秒，因此也一樣被記錄了下來。

若是慢查詢日誌當中的內容不少的話，可使用mysqldmpslow對日誌文件進行分類彙總，

具體使用方式能夠經過mysqldmpslow --help查看使用的參數

 

若是有慢查詢的語句，那麼該如何優化呢

一：對數據entertime列進行建立索引

 

二：優化這個sql查詢語句

 

 

使用mysqldumpslow命令能夠很是明確獲得各類咱們須要的查詢語句；對mysql查詢語句的監控、分析、優化是mysql很是重要的一部分。

 

explain 分析查詢：

使用explain關鍵字能夠模擬優化器執行sql查詢語句；從而知道mysql是如何處理sql語句的。能夠分析查詢語句或表結構的性能瓶頸

 

EXPLAIN字段：

Table：顯示這一行的數據是關於哪張表的

type：這是最重要的字段之一，顯示查詢使用了何種類型。從最好到最差的鏈接類型爲system、const、eq_reg、ref、range、index和ALL

possible_keys：顯示可能應用在這張表中的索引。若是爲空，沒有可能的索引。

key：實際使用的索引。若是爲NULL，則沒有使用索引。

key_len：使用的索引的長度。在不損失精確性的狀況下，長度越短越好

ref：顯示索引的哪一列被使用了，若是可能的話，是一個常數

rows：MySQL認爲必須檢索的用來返回請求數據的行數

Extra：關於MYSQL如何解析查詢的額外信息

從上面的explain模擬優化器執行sql語句來看是沒有使用索引查詢的，而是全表掃描

 

從上面的explain模擬優化器執行sql語句看來沒有使用索引查詢，而是全表掃描

優化方法：

 

 

顯示結果說明該查詢語句使用了index_stuname索引查詢數據而非全表掃描。

 

profiling分析查詢：

經過慢日誌查詢能夠知道那些sql語句執行效率低，經過explain能夠知道sql語句的具體執行狀況；索引等，能夠經過profiling命令獲得更準確的sql執行消耗系統資源的信息。

profiling默認是關閉的，可經過查看的方式：

 

 

或者經過

 

 

 

打開profiling的功能：以下圖

 

 

接下來測試要執行的sql語句

 

 

 

status:是profile裏的狀態，duration：是status狀態下的耗時。所以咱們關注的就是那個狀態最耗時，這些狀態中那些能夠優化。

 

固然也能夠查看更多的信息如CPU等等

SHOW PROFILE [type [, type] ... ]  [FOR QUERY n]

type:
       ALL:顯示全部的開銷信息
      BLOCK IO:顯示塊IO相關開銷
      CPU:顯示用戶CPU時間、系統CPU時間
      IPC:顯示發送和接收相關開銷信息
       PAGE FAULTS:顯示頁面錯誤相關開銷信息
      SWAPS:顯示交換次數相關開銷的信息

測試完成之之後，記得要關閉調試功能，以避免影響數據庫的正常使用：

mysql> set profiling=0;

 

 

 

 

2：配置優化：

mysql參數優化對不一樣的網站，及其線量，訪問量、帖子數量、網絡狀況、以及硬件設備，都有關係，優化不可能一次性完成，須要不斷的觀察以及調試，才能達到最佳效果。

對性能影響比較大的分爲連接請求的變量和緩衝區變量

 

1)鏈接請求的變量

max_connections

mysql的最大鏈接數；若是服務器的併發請求量比較大，建議調高此值，以增長並行鏈接數量，固然這是創建在服務器可以支撐的狀況之下，若是鏈接數越大，mysql回味每一個鏈接提供鏈接緩衝區，這樣內存的開銷會提升。因此要適當的調整該值。不能盲目的提升。

可是若是數值太小的話會出現ERROR 1040：Too many connections的錯誤，能夠經過如下的命令查看鏈接數啊

mysql>show variables like ‘max_connections’ 最大鏈接數

mysql>show  status like ‘max_used_connections’ 響應的鏈接數

max_used_connections / max_connections * 100% （理想值≈ 85%） 

 

 

 

 

 

 

max_used_connections/ max_connections * 100% {理想值=85%}

那麼如何設置max_xonnections？

修改/etc/my.cnf文件，在【mysqld】下面添加以下內容，。如設置最大鏈接數爲1024

max_connections=1024

以後重啓mysql服務

 

2：back_log

mysql能暫存的鏈接數量。當主要mysql線程在一個很短的時間內獲得很是對的鏈接請求；它就會起做用，當mysql；的連接數達到max_connections是，新的請求將會被存放在堆棧當中。等待某一連接，釋放資源，該堆棧的數量即back_log，若是連接數量超過back_log，將不被授予連接資源

back_log值指出在mysql暫時中止回答新請求以前的短期內段時間內有多少個請求能夠被存在堆棧中，若是指望在一個短期內與不少連接，你須要增長它

 

何設置back_log?

修改/etc/my.cnf文件，在[mysqld]下面添加以下內容，如設置最大鏈接數爲1024

back_log = 數值

 

重啓mysql服務

 

 

3. wait_timeout和interactive_timeout

wait_timeout -- 指的是MySQL在關閉一個非交互的鏈接以前所要等待的秒數

interactive_time -- 指的是mysql在關閉一個交互的鏈接以前所要等待的秒數，好比咱們在終端上進入mysql管理，使用的即便交互的鏈接，這時候，若是沒有操做的時間超過了interactive_time設置的時間就會自動斷開。默認數值是28800，可調優爲7200。

對性能的影響：

wait_timeout：

（1）若是設置大小，那麼鏈接關閉的很快，從而使一些持久的鏈接不起做用

（2）若是設置太大，容易形成鏈接打開時間過長，在show processlist時，能看到太多的sleep狀態的鏈接，從而形成too many connections錯誤

 

 

（3）通常但願wait_timeout儘量地低

interactive_timeout的設置將要對你的web application沒有多大的影響

查看wait_timeout和interactive_timeout

mysql> show variables like '%wait_timeout%';

 

mysql> show variables like '%interactive_timeout%';

 

如何設置wait_timeout和interactive_timeout?

修改/etc/my.cnf文件，在[mysqld]下面添加以下內容

wait_timeout=100
interactive_timeout=100

重啓MySQL Server進入後，查看設置已經生效。

2）綬衝區變量

全局緩衝：

4.key_buffer_size

key_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤爲是索引讀的速度。經過檢查狀態值Key_read_requests和Key_reads，能夠知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該儘量的低，至少是1:100，1:1000更好（上述狀態值可使用SHOW STATUS LIKE ‘key_read%’得到）。

 

一共有6個索引讀取請求，有3個請求在內存中沒有找到直接從硬盤讀取索引，計算索引未命中緩存的機率： 
key_cache_miss_rate ＝ Key_reads / Key_read_requests * 100% =50% 

key_buffer_size只對MyISAM表起做用。即便你不使用MyISAM表，可是內部的臨時磁盤表是MyISAM表，也要使用該值。可使用檢查狀態值created_tmp_disk_tables得知詳情。

 

 如何調整key_buffer_size

默認配置數值是8388608(8M)，主機有4GB內存，能夠調優值爲268435456(256MB)

修改/etc/my.cnf文件，在[mysqld]下面添加以下內容

key_buffer_size=268435456或key_buffer_size=256M

重啓MySQL Server進入後，查看設置已經生效。

5.  query_cache_size(查詢緩存簡稱QC)

使用查詢緩衝，MySQL將查詢結果存放在緩衝區中，從此對於一樣的SELECT語句（區分大小寫），將直接從緩衝區中讀取結果。

一個SQL查詢若是以select開頭，那麼MySQL服務器將嘗試對其使用查詢緩存。

注：兩個SQL語句，只要相差哪怕是一個字符（例如大小寫不同；多一個空格等），那麼這兩個SQL將使用不一樣的一個CACHE。

 

經過檢查狀態值’Qcache%’，能夠知道query_cache_size設置是否合理（上述狀態值可使用SHOW STATUS LIKE ‘Qcache%’得到）。

 

Qcache_free_blocks：緩存中相鄰內存塊的個數。若是該值顯示較大，則說明Query Cache 中的內存碎片較多了，FLUSH QUERY CACHE會對緩存中的碎片進行整理，從而獲得一個空閒塊。 

注：當一個表被更新以後，和它相關的cache blocks將被free。可是這個block依然可能存在隊列中，除非是在隊列的尾部。能夠用FLUSH QUERY CACHE語句來清空free blocks
Qcache_free_memory：Query Cache 中目前剩餘的內存大小。經過這個參數咱們能夠較爲準確的觀察出當前系統中的Query Cache 內存大小是否足夠，是須要增長仍是過多了。
Qcache_hits：表示有多少次命中緩存。咱們主要能夠經過該值來驗證咱們的查詢緩存的效果。數字越大，緩存效果越理想。
Qcache_inserts：表示多少次未命中而後插入，意思是新來的SQL請求在緩存中未找到，不得不執行查詢處理，執行查詢處理後把結果insert到查詢緩存中。這樣的狀況的次數越多，表示查詢緩存應用到的比較少，效果也就不理想。固然系統剛啓動後，查詢緩存是空的，這很正常。
Qcache_lowmem_prunes：多少條Query 由於內存不足而被清除出Query Cache。經過「Qcache_lowmem_prunes」和「Qcache_free_memory」相互結合，可以更清楚的瞭解到咱們系統中Query Cache 的內存大小是否真的足夠，是否很是頻繁的出現由於內存不足而有Query 被換出。這個數字最好長時間來看；若是這個數字在不斷增加，就表示可能碎片很是嚴重，或者內存不多。（上面的free_blocks和free_memory能夠告訴您屬於哪一種狀況） 
Qcache_not_cached：不適合進行緩存的查詢的數量，一般是因爲這些查詢不是 SELECT 語句或者用了now()之類的函數。 
Qcache_queries_in_cache：當前Query Cache 中cache 的Query 數量； 
Qcache_total_blocks：當前Query Cache 中的block 數量；。 

咱們再查詢一下服務器關於query_cache的配置：

 

上圖能夠看出query_cache_type爲ON表示緩存任何查詢

各字段的解釋：
query_cache_limit：超過此大小的查詢將不緩存 
query_cache_min_res_unit：緩存塊的最小大小 ，query_cache_min_res_unit的配置是一柄」雙刃劍」，默認是4KB，設置值大對大數據查詢有好處，但若是你的查詢都是小數據查詢，就容易形成內存碎片和浪費。
query_cache_size：查詢緩存大小 (注：QC存儲的最小單位是1024 byte，因此若是你設定了query_cache_type：緩存類型，決定緩存什麼樣的查詢，注意這個值不能隨便設置，必須設置爲數字，可選項目以及說明以下：

 

若是設置爲0，那麼能夠說，你的緩存根本就沒有用，至關於禁用了。

若是設置爲1，將會緩存全部的結果，除非你的select語句使用SQL_NO_CACHE禁用了查詢緩存。

若是設置爲2，則只緩存在select語句中經過SQL_CACHE指定須要緩存的查詢。

修改/etc/my.cnf,配置完後的部分文件以下：

query_cache_size=256M

保存文件，從新啓動MYSQL服務，而後經過以下查詢來驗證開啓了：

 

 

query_cache_wlock_invalidate：當有其餘客戶端正在對MyISAM表進行寫操做時，若是查詢在query cache中，是否返回cache結果仍是等寫操做完成再讀表獲取結果。  

查詢緩存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100% 
若是查詢緩存碎片率超過20%，能夠用FLUSH QUERY CACHE整理緩存碎片，或者試試減少query_cache_min_res_unit，若是你的查詢都是小數據量的話。 
查詢緩存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100% 
查詢緩存利用率在25%如下的話說明query_cache_size設置的過大，可適當減少；查詢緩存利用率在80％以上並且Qcache_lowmem_prunes > 50的話說明query_cache_size可能有點小，要不就是碎片太多。
查詢緩存命中率 = Qcache_hits/(Qcache_hits +Qcache_inserts) * 100% 

 

Query Cache 的限制

a) 全部子查詢中的外部查詢SQL 不能被Cache；
b) 在Procedure，Function 以及Trigger 中的Query 不能被Cache；
c) 包含其餘不少每次執行可能獲得不同結果的函數的Query不能被Cache。
鑑於上面的這些限制，在使用Query Cache 的過程當中，建議經過精確設置的方式來使用，僅僅讓合適的表的數據能夠進入Query Cache，僅僅讓某些Query的查詢結果被Cache。

如何設置query_cache_size？

修改/etc/my.cnf文件，在[mysqld]下面添加以下內容

query_cache_size=256M
query_cache_type=1

重啓MySQL Server進入後，查看設置已經生效。

 

6. max_connect_errors是一個MySQL中與安全有關的計數器值，它負責阻止過多嘗試失敗的客戶端以防止暴力破解密碼的狀況, 當超過指定次數，MYSQL服務器將禁止host的鏈接請求，直到mysql服務器重啓或經過flush hosts命令清空此host的相關信息。max_connect_errors的值與性能並沒有太大關係。

修改/etc/my.cnf文件，在[mysqld]下面添加以下內容

max_connect_errors=20

重啓MySQL Server進入後，查看設置已經生效。

 

 

 

 

         MySQL性能優化————影響性能的因素

若是將mysql服務器比做一臺跑車，那麼服務器硬件就比如發動機，引擎等公具，而裏面的設施皮椅就能夠比做MySQL的性能優化，只有二者兼備纔算的上是一個完整的跑車；

在這裏咱們主要針對的是對mysql的性能進行優化屬於剛纔說的裏面的設施。

包括鏈接數，查詢緩存等

 

MySQL影響性能的因素：

1.商業需求的影響

2.系統架構及實現的影響

1）二進制多媒體數據

2）超大文本數據

3：sql語句使用的不恰當，以及優化先後的變化

在數據庫中最主要的優化包括cpu、內存和磁盤i/o的優化

固然這些必須根據自身公司的服務器進行判斷：好比CPU能夠支持多核，內存最小64GB、以上等等

例子：爲查詢緩存優化你的查詢

大多數MySQL已經開啓了查詢緩存，這是最有效提升優化的方法之一；不少相同的查詢執行屢次，被放到一個緩存當中，後續獲得查詢就不用操做表而直接訪問緩存當中的數據

 query_cache_size(查詢緩存簡稱QC)

注：兩個SQL語句，只要相差哪怕是一個字符（例如大小寫不同；多一個空格等），那麼這兩個SQL將使用不一樣的一個CACHE。

經過檢查狀態值’Qcache%’，能夠知道query_cache_size設置是否合理（上述狀態值可使用SHOW STATUS LIKE ‘Qcache%’得到）。

 

Qcache_free_blocks：緩存中相鄰內存塊的個數。若是該值顯示較大，則說明Query Cache 中的內存碎片較多了，FLUSH QUERY CACHE會對緩存中的碎片進行整理，從而獲得一個空閒塊。 

注：當一個表被更新以後，和它相關的cache blocks將被free。可是這個block依然可能存在隊列中，除非是在隊列的尾部。能夠用FLUSH QUERY CACHE語句來清空free blocks
咱們再查詢一下服務器關於query_cache的配置：

 

上圖能夠看出query_cache_type爲off表示不緩存任何查詢

各字段的解釋：
query_cache_limit：超過此大小的查詢將不緩存 
query_cache_min_res_unit：緩存塊的最小大小 ，query_cache_min_res_unit的配置是一柄」雙刃劍」，默認是4KB，設置值大對大數據查詢有好處，但若是你的查詢都是小數據查詢，就容易形成內存碎片和浪費。
query_cache_size：查詢緩存大小 (注：QC存儲的最小單位是1024 byte，因此若是你設定了一個不是1024的倍數的值，這個值會被四捨五入到最接近當前值的等於1024的倍數的值。)
query_cache_type：緩存類型，決定緩存什麼樣的查詢，注意這個值不能隨便設置，必須設置爲數字，可選項目以及說明以下：

 

若是設置爲0，那麼能夠說，你的緩存根本就沒有用，至關於禁用了。

若是設置爲1，將會緩存全部的結果，除非你的select語句使用SQL_NO_CACHE禁用了查詢緩存。

若是設置爲2，則只緩存在select語句中經過SQL_CACHE指定須要緩存的查詢。

query_cache_wlock_invalidate：當有其餘客戶端正在對MyISAM表進行寫操做時，若是查詢在query cache中，是否返回cache結果仍是等寫操做完成再讀表獲取結果。 

修改/etc/my.cnf,配置完後的部分文件以下：

query_cache_size=256M
query_cache_type=1

保存文件，從新啓動MYSQL服務，而後經過以下查詢來驗證是否真正開啓了：

 

2：explain你的select查詢

幫助你查看你的mysql是如何處理的的sql語句，分析你的查詢語句或者表結構的性能瓶頸。

另外還會告訴你使用的是什麼索引；數據表是如何被搜索的和排序的

 

explain分析查詢

使用 EXPLAIN 關鍵字能夠模擬優化器執行SQL查詢語句，從而知道MySQL是如何處理你的SQL語句的。這能夠幫你分析你的查詢語句或是表結構的性能瓶頸。經過explain命令能夠獲得:

 

> explain select * from test1.tb1 where stuname='admin'\G;

profiling分析查詢

經過慢日誌查詢能夠知道哪些SQL語句執行效率低下，經過explain咱們能夠得知SQL語句的具體執行狀況，索引使用等，還能夠結合show命令查看執行狀態。若是以爲explain的信息不夠詳細，能夠同經過profiling命令獲得更準確的SQL執行消耗系統資源的信息。

profiling默認是關閉的。能夠經過如下語句查看

mysql> show variables like '%profiling%';    //off表示未開啓

打開profiling功能： mysql>set profiling=1; 執行須要測試的sql 語句：

mysql> select @@profiling;

+---------------------+

| @@profiling |

+---------------------+

|           1 |

+----------------------+

執行要測試的sql語句

mysql> select * from test1.tb1 where stuname='admin' and entertime='2016-9-1';

mysql> show profiles\G;   //能夠獲得被執行的SQL語句的時間和ID

*************************** 1. row ***************************

Query_ID: 1

Duration: 0.00012650

   Query: select @@profiling

*************************** 2. row ***************************

Query_ID: 2

Duration: 0.00121725

   Query: select * from test1.tb1 where stuname='admin' and entertime='2016-9-1'

mysql> show profile for query 2;  //獲得對應SQL語句執行的詳細信息

+----------------------+-------------------------+

| Status              | Duration |

+----------------------+-------------------------+

| starting             | 0.000230 |

| checking permissions | 0.000013 |

| Opening tables       | 0.000030 |

| init                 | 0.000087 |

| System lock          | 0.000018 |

| optimizing           | 0.000128 |

| statistics           | 0.000378 |

| preparing            | 0.000026 |

| executing            | 0.000005 |

| Sending data         | 0.000187 |

| end                  | 0.000013 |

| query end            | 0.000011 |

| closing tables       | 0.000010 |

| freeing items        | 0.000061 |

| cleaning up          | 0.000021 |

+----------------------+-------------------------+

status:是profile裏的狀態，duration：是status狀態下的耗時。所以咱們關注的就是那個狀態最耗時，這些狀態中那些能夠優化。

固然也能夠查看更多的信息如CPU等等

SHOW PROFILE [type [, type] ... ][FOR QUERY n]

type:
       ALL:顯示全部的開銷信息
      BLOCK IO:顯示塊IO相關開銷
      CPU:顯示用戶CPU時間、系統CPU時間
      IPC:顯示發送和接收相關開銷信息
       PAGE FAULTS:顯示頁面錯誤相關開銷信息
      SWAPS:顯示交換次數相關開銷的信息

測試完成之之後，記得要關閉調試功能，以避免影響數據庫的正常使用：

mysql> set profiling=0;

 

3:爲搜索字段創建索引:

索引並不必定給主鍵或是字段創建，而是給常常須要查詢的目標創建，至關於字典的目錄，提速高效能。提升查詢效率，快速定位數據 

索引分爲四種：

 CREATE INDEX indexName ON tablename(column1[,column2,……])

 

 全文索引 

只用於MyISAM 表 對文本域進行索引。字段類型包括char、varchar、text

不過切記對於大容量的數據表，生成全文索引是一個很是消耗時間很是消耗硬盤空間的作法。

CREATE FULLTEXT INDEX indexname ON tablename(column)

 

全局緩衝：索引緩存的大小

.key_buffer_size

key_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤爲是索引讀的速度。經過檢查狀態值Key_read_requests和Key_reads，能夠知道key_buffer_size設置是否合理。

 如何調整key_buffer_size

默認配置數值是8388608(8M)，主機有4GB內存，能夠調優值爲268435456(256MB)

修改/etc/my.cnf文件，在[mysqld]下面添加以下內容

key_buffer_size=268435456或key_buffer_size=256M

innodb_buffer_pool_size的做用就至關於key_buffer_size對於MyISAM表的做用同樣。InnoDB使用該參數指定大小的內存來緩衝數據和索引。

4：避免select*的使用：

若是數據庫的數據過多的話使用‘*’增長查詢的時間增大cpu和i/o的負載，全表查詢並且速度慢，應該養成查詢的時候制定某一個字段，

 

5：選擇正確的存儲引擎：

myisam使用與查詢大量的的應用；有時一個update字段，可能致使全表鎖定，固然在count（*）這類計算的時候是速度很是快的由於有計數器

innodb複雜的存儲引擎支持行鎖，換支持事物，不適合count（*）

 

6:查看慢查詢日誌：

 

慢查詢日誌開啓：

在配置文件my.cnf中在[mysqld]一行下面加入3個配置參數，並重啓mysql服務

slow_query_log = 1   //0關閉  1開啓
slow_query_log_file = /usr/local/mysql/data/slow-query.log    //慢查詢日誌存放地點

long_query_time = 1                               //表示查詢超過1秒才記錄                                

在my.cnf中添加log-queries-not-using-indexes參數，表示向慢查詢日誌中記錄下沒有使用索引的查詢。

慢查詢日誌開啓方法二：

咱們也能夠經過命令行設置變量來即時啓動慢日誌查詢

mysql> set global slow_query_log = on;

mysql> set long_query_time =0.01;

mysql> set global slow_query_log_file = "/usr/local/mysql/data/slow-query.log";

查看慢查詢的設置信息

mysql> show variables like '%slow_query_log%';

mysql> show variables like '%long_query_time%';

咱們能夠經過打開log文件查看得知哪些SQL執行效率低下

[root@localhost data]# cat slow-query.log 

 

 

7：大批量數據的限制：

若是大批量的添加數據會致使查詢效率低，還有就是數據入庫的時間長，有時候會長達幾個小時

max_allowed_packet = 32M

MySQL根據配置文件會限制Server接受的數據包大小。有時候大的插入和更新會受 max_allowed_packet 參數限制，致使寫入或者更新失敗。最大值是1GB，必須設置1024的倍數。

 

8：關閉交互式：

好比當dba使用交互式的界面對數據庫進行增、改、刪、查以後，忘記了退出數據庫的交互式頁面，若是有人看見在上面進行操做修改數據，會爲公司形成不可估量的損失，在這裏咱們能夠經過只配置文件調整交互式存在的時間，防止其餘人員進行操做；

另外也能夠釋放一個用戶的連接數，增大一個連接數量

.wait_timeout和interactive_timeout

wait_timeout -- 指的是MySQL在關閉一個非交互的鏈接以前所要等待的秒數

interactive_time -- 指的是mysql在關閉一個交互的鏈接以前所要等待的秒數，好比咱們在終端上進入mysql管理，使用的即便交互的鏈接，這時候，若是沒有操做的時間超過了interactive_time設置的時間就會自動斷開。默認數值是28800{8小時}，可調優爲7200。

 

9：增大用戶連接數：

有時候忽然之間數據庫的性能變慢；連接客戶須要好長的時間才能的到響應，甚至有時候收不到，客戶就會不斷的進行連接，這樣數據庫就更加的繁忙了，最後狀況嚴重的話可能致使數據庫掛機，這裏須要設置最大連接數量

 

1.max_connections

MySQL的最大鏈接數，若是服務器的併發鏈接請求量比較大，建議調高此值，以增長並行鏈接數量，固然這創建在機器能支撐的狀況下，由於若是鏈接數越多， MySQL會爲每一個鏈接提供鏈接緩衝區，就會開銷越多的內存，因此要適當調整該值，不能盲目提升設值。

mysql>show variables like ‘max_connections’ 最大鏈接數

mysql>show  status like ‘max_used_connections’響應的鏈接數

max_used_connections / max_connections * 100% （理想值≈ 85%） 

若是max_used_connections跟max_connections相同那麼就是max_connections設置太低或者超過服務器負載上限了，低於10%則設置過大。

如何設置max_connections?

修改/etc/my.cnf文件，在[mysqld]下面添加以下內容，如設置最大鏈接數爲1024

max_connections = 1024

 

10：MySQL的堆棧設置：2.back_log

若是當連接數用戶過多，並且連接的最大數量不夠使用的時候能夠設置堆棧，相似一個房間，講過多的連接先存放起來，等處理完以前的連接以後再處理房間裏的連接，若是等待鏈接的數量超過back_log，將不被授予鏈接資源。

back_log值指出在MySQL暫時中止回答新請求以前的短期內有多少個請求能夠被存在堆棧中。只有若是指望在一個短期內有不少鏈接，你須要增長它。

當觀察你主機進程列表（mysql> show full processlist），發現大量

xxxxx | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待鏈接進程時，就要加大back_log 的值了或加大max_connections的值。

經過mysql> show variables like 'back_log';查看back_log的設置

如何設置back_log?

修改/etc/my.cnf文件，在[mysqld]下面添加以下內容，如設置最大鏈接數爲1024

back_log = 數值{1024}

重啓mysql服務