mysql效能問題定位

使用mysql作為基礎資料庫的應用，可能會遇到一些資料庫方面的效能問題，我們可以通過一些方法進行問題定位。以下介紹可以定位效能問題的四種方法，歡迎拍磚。

一、開啟慢查詢日誌：

記錄執行查詢時間大於long_query_time的sql，long_query_time預設為2s;

show variables like 『%slow%』

得到圖中所示資訊，這裡可以檢視到慢查詢日誌是否開啟，慢查詢日誌檔案的存放目錄。

開啟慢查詢日誌的方法：

1、vi /etc/my.cnf(這個是mysql的預設讀取配置檔案目錄，一般會將my.cnf檔案放在這下面)

[mysqld]下新增

slow_query_log=on

long_query_time=1(sql語句執行時間超過該引數值，則會列印在慢查詢日誌中），預設執行時間超過2s的sql會列印在慢查詢日誌中。

修改了my.cnf中的配置項，需要重啟資料庫。

2、不重啟資料庫的情況下，執行 set global slow_query_log=on，可以開啟慢查詢日誌。

開啟慢查詢日誌後，跟蹤慢查詢日誌檔案中的慢查詢sql，再具體分析，通過調整sql寫法，或者新增正確的索引，可以看到意想不到的效能效果。

二、分析慢查詢sql:

1、explain列印執行計畫

執行的selcet語句前面加上explain，可以告訴你mysql如何執行該條語句。

這裡需要額外注意type、key、rows 、extra列展示的內容。

其中，type=all，表示使用的是全表掃瞄，在資料量大的情況下，全表掃瞄是非常耗效能的，這個需要特別注意；

type=index，表示使用索引掃瞄，只會遍歷索引樹；

type=range,表示使用索引範圍掃瞄，常見於between 、>、《等的查詢。

type=ref，非唯一性索引掃，返回匹配某個單獨值得所有行

type=eq_ref 唯一性索引掃瞄，對於每個索引鍵，表中只有一條記錄與之匹配

type=const/system 讀常量，最多隻會有一條記錄匹配，由於是常量，實際上只須要讀一次

type=null 不需要掃瞄表

訪問型別從上到下由差變為最好。

key表示select中使用到的索引，如果為null，表示沒有使用索引，從查詢效率上講，使用索引比不使用索引快。但並不是所有的都要加索引，索引也存在不足，這裡就不詳解。

rows表示執行該條sql所需要掃瞄的行數，這個沒有絕對值可參考，一般來說越小越好，如果100萬資料量的資料庫，rows是70萬，通過這個可以判斷sql的查詢效能很差，如果100萬條資料量的資料庫，rows是1萬，從我個人的角度，還是能接受的。

extra

一些十分重要的額外資訊，重點關注出現關鍵字：

using filesort：當query 中包含order by 操作，而且無法利用索引完成排序操作的時候，mysql query optimizer 不得不選擇相應的排序演算法來實現。

using temporary:在某些操作中必須使用臨時表時，在 extra 資訊中就會出現using temporary ,主要常見於 group by 和 order by 等操作中

當執行計畫extra 出現using filesort 、using temporary 時，可以考慮是否需要進行sql優化和調整索引，最後再調整my.cnf 中與排序或者臨時表相關的引數，如sort_buffer_size或者tmp_table_size.

2、show full processlist檢視哪條sql一直占用程序

time表示執行當前操作所耗費的時間，單位為秒（s）；

state表面當前執行緒的狀態,info表示正在執行的操作;

這裡如果發現time值比較大，state一直處於乙個狀態，那麼從info中我們可以獲得耗時長的操作，再具體分析；

注意觀察state中出現關於lock關鍵字的狀態。

這個命令可以很直觀地看到正在執行的sql，及其當前狀態，操作比較方便。

3、show profile定位sql在資料庫中資源占用情況（注意，乙個是show profiles,乙個是show profile）

show profiles主要展示在當前會話中，profiling_history_size條sql執行的時間、query_id，預設為15條，最大為100條，不能設為0。

show variables like 『%profiling_history_size%』

show variables like 『%profiling』或者select @@profiling 檢視profiling是否開啟

set profiling=1 開啟profiling

執行一條sql

再執行show profiles,會把最近執行的sql給展示出來，

從圖中找到剛剛執行的sql,query_id是120，執行時間是0.00079725s

如果我們想看sql在各個階段所消耗時間，則使用如下

各個階段所消耗時間一目了然。

show profile具體寫法為 show profile type for query n，n為query_id，type可寫可不寫

type的取值有為all、block io、context switches、cpu、ipc、memory、page faults、source、swaps

如上述例子中

不加for query n這句，則展示執行show profile之前執行過一條語句。

4、mysqladmin查詢整個資料庫的狀態

在mysql的bin目錄下，執行

./mysqladmin -u使用者名稱 -p密碼 proc stat

這裡新增proc就如同show full processlist功效

stat展示當前資料庫的狀態

threads 表示當前執行緒數，opens 當前開啟的表數目，queries per second 每秒執行的查詢數，資料庫效能越好，這個值就越高

mysql效能問題定位

mysql效能問題定位

MYSQL 效能瓶頸定位

Linux效能優化及效能問題定位

mysql效能問題定位

mysql效能問題定位

MYSQL 效能瓶頸定位

Linux效能優化及效能問題定位

相關推薦