mysql 執行狀態分析 執行故障排查
目錄
一、優化概述
二、查詢與索引優化分析
1效能瓶頸定位
Show命令
慢查詢日誌
explain分析查詢
profiling分析查詢
2索引及查詢優化
一、優化概述
MySQL資料庫是常見的兩個瓶頸是CPU和I/O的瓶頸,CPU在飽和的時候一般發生在資料裝入記憶體或從磁碟上讀取資料時候。磁碟I/O瓶頸發生在裝入資料遠大於記憶體容量的時候,如果應用分佈在網路上,那麼查詢量相當大的時候那麼平瓶頸就會出現在網路上,我們可以用mpstat, iostat, sar和vmstat來檢視系統的效能狀態。
除了伺服器硬體的效能瓶頸,對於MySQL系統本身,我們可以使用工具來優化資料庫的效能,通常有三種:使用索引,使用EXPLAIN分析查詢以及調整MySQL的內部配置。
二、查詢與索引優化分析
在優化MySQL時,通常需要對資料庫進行分析,常見的分析手段有慢查詢日誌,EXPLAIN 分析查詢,profiling分析以及show命令查詢系統狀態及系統變數,通過定位分析效能的瓶頸,才能更好的優化資料庫系統的效能。
show 命令
我們可以通過show命令檢視MySQL狀態及變數,找到系統的瓶頸:
Mysql> show status ——顯示狀態資訊(擴充套件show status like ‘XXX’)
Mysql> show variables ——顯示系統變數(擴充套件show variables like ‘XXX’)show variables like "slow%"
Mysql> show innodb status ——顯示InnoDB儲存引擎的狀態
Mysql> show processlist ——檢視當前SQL執行,包括執行狀態、是否鎖表等
Shell> mysqladmin variables -u username -p password——顯示系統變數
Shell> mysqladmin extended-status -u username -p password——顯示狀態資訊
慢查詢日誌
慢查詢 可以記錄執行時間比較慢的語句 和 未使用索引的語句
一、MySQL資料庫有幾個配置選項可以幫助我們及時捕獲低效SQL語句
1,slow_query_log 這個引數設定為ON,可以捕獲執行時間超過一定數值的SQL語句。
2,long_query_time 當SQL語句執行時間超過此數值時,就會被記錄到日誌中,建議設定為1或者更短(單位秒)。
3,slow_query_log_file 記錄日誌的檔名。
4,log_queries_not_using_indexes 這個引數設定為ON,可以捕獲到所有未使用索引的SQL語句,儘管這個SQL語句有可能執行得挺快。
explain分析查詢
使用 EXPLAIN 關鍵字可以模擬優化器執行SQL查詢語句,從而知道MySQL是如何處理你的SQL語句的。這可以幫你分析你的查詢語句或是表結構的效能瓶頸。通過explain命令可以得到:
– 表的讀取順序
– 資料讀取操作的操作型別
– 哪些索引可以使用
– 哪些索引被實際使用
– 表之間的引用
– 每張表有多少行被優化器查詢
SQLmysql> explain select * from user;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
| 1 | SIMPLE | user | NULL | ALL | NULL | NULL | NULL | NULL | 85 | 100.00 | NULL |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------+
1 row in set, 1 warning (0.01 sec)
EXPLAIN欄位:
id: 查詢序號即為sql語句執行的順序
select_type
select型別,它有以下幾種值
2.1 simple 它表示簡單的select,沒有union和子查詢
2.2 primary 最外面的select,在有子查詢的語句中,最外面的select查詢就是primary,上圖中就是這樣
2.3 union union語句的第二個或者說是後面那一個.現執行一條語句,explain
Table:顯示這一行的資料是關於哪張表的
possible_keys:顯示可能應用在這張表中的索引。如果為空,沒有可能的索引。可以為相關的域從WHERE語句中選擇一個合適的語句
key:實際使用的索引。如果為NULL,則沒有使用索引。MYSQL很少會選擇優化不足的索引,此時可以在SELECT語句中使用USE INDEX(index)來強制使用一個索引或者用IGNORE INDEX(index)來強制忽略索引
key_len:使用的索引的長度。在不損失精確性的情況下,長度越短越好
ref:顯示索引的哪一列被使用了,如果可能的話,是一個常數
rows:MySQL認為必須檢索的用來返回請求資料的行數
type:這是最重要的欄位之一,顯示查詢使用了何種型別。從最好到最差的連線型別為system、const、eq_reg、ref、range、index和ALL
Extra:關於MYSQL如何解析查詢的額外資訊,主要有以下幾種
Extra:引數說明
using index:只用到索引,可以避免訪問表.
using where:使用到where來過慮資料. 不是所有的where clause都要顯示using where. 如以=方式訪問索引.
using tmporary:用到臨時表
using filesort:用到額外的排序. (當使用order by v1,而沒用到索引時,就會使用額外的排序)
range checked for eache record(index map:N):沒有好的索引.
type:引數說明
system、const:可以將查詢的變數轉為常量. 如id=1; id為 主鍵或唯一鍵.
eq_ref:訪問索引,返回某單一行的資料.(通常在聯接時出現,查詢使用的索引為主鍵或惟一鍵)
ref:訪問索引,返回某個值的資料.(可以返回多行) 通常使用=時發生
range:這個連線型別使用索引返回一個範圍中的行,比如使用>或<查詢東西,並且該欄位上建有索引時發生的情況(注:不一定好於index)
index:以索引的順序進行全表掃描,優點是不用排序,缺點是還要全表掃描
ALL:全表掃描,應該儘量避免
profiling分析查詢
通過慢日誌查詢可以知道哪些SQL語句執行效率低下,通過explain我們可以得知SQL語句的具體執行情況,索引使用等,還可以結合show命令檢視執行狀態。
如果覺得explain的資訊不夠詳細,可以同通過profiling命令得到更準確的SQL執行消耗系統資源的資訊。
profiling預設是關閉的。可以通過以下語句檢視 select @@profiling;
開啟功能: mysql>set profiling=1; 執行需要測試的sql 語句:
開啟後執行了sql語句 就可以通過show profiles;命令檢視執行時間
SQLmysql> show profiles;
+----------+------------+---------------------------+
| Query_ID | Duration | Query |
+----------+------------+---------------------------+
| 1 | 0.00417000 | select * from user |
| 2 | 0.00214700 | select count(*) from user |
+----------+------------+---------------------------+
2 rows in set, 1 warning (0.00 sec)
mysql> show profiles\G; 可以得到被執行的SQL語句的時間和ID
mysql>show profile for query 1; 得到對應SQL語句執行的詳細資訊
Bashmysql> show profile for query 1; +----------------------+----------+ | Status | Duration | +----------------------+----------+ | starting | 0.001587 || checking permissions | 0.000351 || Opening tables | 0.000015 || init | 0.000021 || System lock | 0.000264 || optimizing | 0.000014 || statistics | 0.000014 || preparing | 0.000012 || executing | 0.000003 || Sending data | 0.001485 || end | 0.000018 || query end | 0.000120 || closing tables | 0.000026 || freeing items | 0.000157 || cleaning up | 0.000083 | +----------------------+----------+ 15 rows in set, 1 warning (0.00 sec)
相關推薦
mysql 執行狀態分析 執行故障排查
目錄 一、優化概述 二、查詢與索引優化分析 1效能瓶頸定位 Show命令 慢查詢日誌 explain分析查詢 profiling分析查詢 2索引及查詢優化 一、優化概述 MySQL資料庫是常見的兩個瓶頸是CPU和I/
Linux系統之執行狀態分析及問題排查思路
〇、一件事兒 以下分析是站在Java工程師的角度來分析的。 一、CPU分析 分析CPU的繁忙程度,兩個指標:系統負載和CPU利用率 1、系統負載分析 系統負載:在Linux系統中表示,一段時間內正在執行程序數和CPU執行佇列中就緒等待程序數,以及非常重要的休眠但不可中斷的程序數的平均值(具體load值的計算
Java執行狀態分析1:執行緒及執行緒狀態
執行緒 執行緒(英語:thread)是作業系統能夠進行運算排程的最小單位。它被包含在程序之中,是程序中的實際運作單位。一條執行
Java執行狀態分析2:獲取執行緒堆疊資訊
Java執行狀態分析2:獲取執行緒堆疊資訊 基本概念 出現記憶體洩漏或者執行緩慢場景,有時候無法直接從業務日誌看出問題時候
Java執行狀態分析3: 執行緒堆疊資訊分析
背景 當CPU飆升的時候,我們需要知道CPU此時在幹嘛,具體什麼程序、什麼執行緒讓CPU飆升 執行緒是作業系統能夠進行運算排
伺服器開發中網路資料分析與故障排查經驗漫談
寫在前面的話 “聽見學生時代愛聽的歌,加上太累,回家路上一下子想了好多,腳步慢了,眼眶溼了,不是感傷,而是生活呀,需要這麼多力量。過去那些跌跌撞撞忙碌的日子,怎麼說呢,多少有點像在逃避吧,聽起來不像是真的。” 以上這段話訴說了我的經歷,我也曾迷惘和無助過。也有很多朋友找
伺服器故障排查 如何使用jstack分析執行緒狀態
使用jstack精確找到異常程式碼的:https://blog.csdn.net/Mr__fang/article/details/68496248?utm_source=blogxgwz0 Java記憶體洩漏分析系列之一:使用jstack定位執行緒堆疊資訊:https://www.javatang.com
mysql 執行計劃分析三看, explain,profiling,optimizer_trace
roc var you time field 表之間 origin 依賴 nod http://blog.csdn.net/xj626852095/article/details/52767963 step 1 使用explain 查看執行計劃, 5.6後可以加參數
MySQL——通過EXPLAIN分析SQL的執行計劃
_id ble custom sql遍歷 extra clas soft sql tom 在MySQL中,我們可以通過EXPLAIN命令獲取MySQL如何執行SELECT語句的信息,包括在SELECT語句執行過程中表如何連接和連接的順序。 下面分別對EXPLAIN命令結果
MySQL執行狀態show status中文詳
狀態名 作用域 詳細解釋 Aborted_clients Global 由於客戶端沒有正確關閉連線導致客戶端終止而中斷的連線數 Aborted_connect
Linux Centos7通過shell指令碼來監控mysql的執行狀態
vim checkmysql.sh #!/bin/sh #create by mingongge at 2018-10-10 port=`netstat -lnt|grep 3306|wc -l` if [ $post -ne 1 ] ;then now
【MySQL】SQL執行計劃分析
https://blog.csdn.net/da_guo_li/article/details/79008016 執行計劃能告訴我們什麼? 當我們的系統上線後資料庫的記錄不斷增加,之前寫的一些SQL語句或者一些ORM操作效率變得非常低。我們不得不考慮SQ
jstack執行緒狀態分析
jstack Dump 日誌檔案中的執行緒狀態 dump 檔案裡,值得關注的執行緒狀態有: 死鎖,Deadlock(重點關注) 執行中,Runnable 等待資源,Waiting on condition(重點關注)
mysql優化–explain分析sql語句執行效率
Explain命令在解決資料庫效能上是第一推薦使用命令,大部分的效能問題可以通過此命令來簡單的解決,Explain可以用來檢視SQL語句的執行效 果,可以幫助選擇更好的索引和優化查詢語句,寫出更好的優化語句。 Explain語法:explain select … from …
mysql 架構篇系列 3 複製執行狀態監控與選項引數說明
一. 概述 在上一篇中,搭建了一主一從的複製架構,這篇通過一些診斷方法來了解複製的執行狀態和一些選項引數說明。上次mysql主從服務關機,今天在開啟mysql服務,出現了錯誤資訊。 1.首先 啟動主從mysql服務 2.在從庫上執行START SLAVE, 開始複製。 3.在從庫上執行SHOW
Mysql學習-02 sql執行順序與索引分析
1.效能下降SQL慢 執行時間長 等待時間長原因: 查詢資料過多 關聯了太多的表,太多join 沒有充分利用到索引 -- > 單值,複合 Mysql一般情況下,查詢一張表只會用到其中的一個索引,所以單值索引有時候並不能把sql的查詢條件都納入索引查詢
如何使用 jstack 分析執行緒狀態
背景 記得前段時間,同事說他們測試環境的伺服器cpu使用率一直處於100%,本地又沒有什麼介面呼叫,為什麼會這樣?cpu使用率居高不下,自然是有某些執行緒一直佔用著cpu資源,那又如何檢視佔用cpu較高的執行緒? 當然一個正常的程式設計師不會寫出上述程式碼,這
MySQL 5.7新增sys.session表檢視系統執行狀態
在MySQL 5.6以前,我們通過show processlist\G命令檢視系統中正在執行的所有程序,從5.7開始,我們又可以通過sys.session表來檢視系統正在執行的所有程序,而且該表中的記錄相對processlist比較完善:mysql> SELECT
MYSQL優化原理和執行計劃分析(一)
索引基礎 效能下降SQL慢執行時間長等待時間長 查詢資料過多 (能不能拆,條件過濾儘量少) 關聯了太多的表,太多join (join 原理。用 A 表的每一條資
如何使用jstack分析執行緒狀態
背景 記得前段時間,同事說他們測試環境的伺服器cpu使用率一直處於100%,本地又沒有什麼介面呼叫,為什麼會這樣?cpu使用率居高不下,自然是有某些執行緒一直佔用著cpu資源,那又如何檢視佔用cpu較高的執行緒? 當然一個正常的程式設計師不會寫出上述程式碼,這裡只