mysql效能問題定位

2021-08-27 16:34:41 字數 3173 閱讀 4569

2013 年 8 月 28 日, by

徐旭 , 所屬分類

資料庫,

測試技術.

使用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 for query 120

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

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

如上述例子中

show profile cpu,memory for query 120

不加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作為基礎資料庫的應用,可能會遇到一些資料庫方面的效能問題,我們可以通過一些方法進行問題定位。以下介紹可以定位效能問題的四種方法,歡迎拍磚。一 開啟慢查詢日誌 記錄執行查詢時間大於long query time的sql,long query time預設為2s show variable...

MYSQL 效能瓶頸定位

查詢與索引優化分析 在優化mysql時,通常需要對資料庫進行分析,常見的分析手段有慢查詢日誌,explain 分析查詢,profiling分析以及show命令查詢系統狀態及系統變數,通過定位分析效能的瓶頸,才能更好的優化資料庫系統的效能。1 效能瓶頸定位show命令 我們可以通過show命令檢視my...

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

效能優化是什麼?1.1 效能優化就是發揮機器本來的效能 效能的幾個唯度 1.1.1 cpu 命令 vmstat 首先檢查 cpu,cpu 使用率要提公升而不是降低 cpu 空閒並不一定是沒事做,也有可能是鎖或者外部資源瓶頸。命令 top 命令 iostat 命令 free 命令 nicstat 需要...