⑴ 如何開啟Mysql慢查詢日誌
一、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語句有可能執行得挺快。二、檢測mysql中sql語句的效率的方法1、通過查詢日誌（1）、Windows下開啟MySQL慢查詢MySQL在Windows系統中的配置文件一般是是my.ini找到[mysqld]下面加上代碼如下log-slow-queries=F:/MySQL/log/mysqlslowquery。loglong_query_time=2（2）、Linux下啟用MySQL慢查詢MySQL在Windows系統中的配置文件一般是是my.cnf找到[mysqld]下面加上代碼如下log-slow-queries=/data/mysqldata/slowquery。loglong_query_time=2說明log-slow-queries=F:/MySQL/log/mysqlslowquery。為慢查詢日誌存放的位置，一般這個目錄要有MySQL的運行帳號的可寫許可權，一般都將這個目錄設置為MySQL的數據存放目錄；long_query_time=2中的2表示查詢超過兩秒才記錄；2.showprocesslist命令SHOWPROCESSLIST顯示哪些線程正在運行。您也可以使用mysqladminprocesslist語句得到此信息。各列的含義和用途：ID列一個標識，你要kill一個語句的時候很有用，用命令殺掉此查詢/*/mysqladminkill進程號。user列顯示單前用戶，如果不是root，這個命令就只顯示你許可權范圍內的sql語句。host列顯示這個語句是從哪個ip的哪個埠上發出的。用於追蹤出問題語句的用戶。db列顯示這個進程目前連接的是哪個資料庫。command列顯示當前連接的執行的命令，一般就是休眠（sleep），查詢（query），連接（connect）。time列此這個狀態持續的時間，單位是秒。state列顯示使用當前連接的sql語句的狀態，很重要的列，後續會有所有的狀態的描述，請注意，state只是語句執行中的某一個狀態，一個sql語句，以查詢為例，可能需要經過ingtotmptable，Sortingresult，Sendingdata等狀態才可以完成info列顯示這個sql語句，因為長度有限，所以長的sql語句就顯示不全，但是一個判斷問題語句的重要依據。這個命令中最關鍵的就是state列，mysql列出的狀態主要有以下幾種：Checkingtable正在檢查數據表（這是自動的）。Closingtables正在將表中修改的數據刷新到磁碟中，同時正在關閉已經用完的表。這是一個很快的操作，如果不是這樣的話，就應該確認磁碟空間是否已經滿了或者磁碟是否正處於重負中。ConnectOut復制從伺服器正在連接主伺服器。Copyingtotmptableondisk由於臨時結果集大於tmp_table_size，正在將臨時表從內存存儲轉為磁碟存儲以此節省內存。Creatingtmptable正在創建臨時表以存放部分查詢結果。deletingfrommaintable伺服器正在執行多表刪除中的第一部分，剛刪除第一個表。deletingfromreferencetables伺服器正在執行多表刪除中的第二部分，正在刪除其他表的記錄。Flushingtables正在執行FLUSHTABLES，等待其他線程關閉數據表。Killed發送了一個kill請求給某線程，那麼這個線程將會檢查kill標志位，同時會放棄下一個kill請求。MySQL會在每次的主循環中檢查kill標志位，不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了，那麼kill請求會在鎖釋放時馬上生效。Locked被其他查詢鎖住了。Sendingdata正在處理SELECT查詢的記錄，同時正在把結果發送給客戶端。Sortingforgroup正在為GROUPBY做排序。Sortingfororder正在為ORDERBY做排序。Openingtables這個過程應該會很快，除非受到其他因素的干擾。例如，在執ALTERTABLE或LOCKTABLE語句行完以前，數據表無法被其他線程打開。正嘗試打開一個表。Removingplicates正在執行一個SELECTDISTINCT方式的查詢，但是MySQL無法在前一個階段優化掉那些重復的記錄。因此，MySQL需要再次去掉重復的記錄，然後再把結果發送給客戶端。Reopentable獲得了對一個表的鎖，但是必須在表結構修改之後才能獲得這個鎖。已經釋放鎖，關閉數據表，正嘗試重新打開數據表。Repairbysorting修復指令正在排序以創建索引。Repairwithkeycache修復指令正在利用索引緩存一個一個地創建新索引。它會比Repairbysorting慢些。Searchingrowsforupdate正在講符合條件的記錄找出來以備更新。它必須在UPDATE要修改相關的記錄之前就完成了。Sleeping正在等待客戶端發送新請求.Systemlock正在等待取得一個外部的系統鎖。如果當前沒有運行多個mysqld伺服器同時請求同一個表，那麼可以通過增加--skip-external-locking參數來禁止外部系統鎖。UpgradinglockINSERTDELAYED正在嘗試取得一個鎖表以插入新記錄。Updating正在搜索匹配的記錄，並且修改它們。UserLock正在等待GET_LOCK()。Waitingfortables該線程得到通知，數據表結構已經被修改了，需要重新打開數據表以取得新的結構。然後，為了能的重新打開數據表，必須等到所有其他線程關閉這個表。以下幾種情況下會產生這個通知：FLUSHTABLEStbl_name,ALTERTABLE,RENAMETABLE,REPAIRTABLE,ANALYZETABLE,或OPTIMIZETABLE。已經處理完了所有待處理的插入操作，正在等待新的請求。大部分狀態對應很快的操作，只要有一個線程保持同一個狀態好幾秒鍾，那麼可能是有問題發生了，需要檢查一下。還有其他的狀態沒在上面中列出來，不過它們大部分只是在查看伺服器是否有存在錯誤是才用得著。例如如圖：3、explain來了解SQL執行的狀態explain顯示了mysql如何使用索引來處理select語句以及連接表。可以幫助選擇更好的索引和寫出更優化的查詢語句。使用方法，在select語句前加上explain就可以了：例如：explainselectsurname,first_nameforma,bwherea.id=b.id結果如圖EXPLAIN列的解釋table顯示這一行的數據是關於哪張表的type這是重要的列，顯示連接使用了何種類型。從最好到最差的連接類型為const、eq_reg、ref、range、indexhe和ALLpossible_keys顯示可能應用在這張表中的索引。如果為空，沒有可能的索引。可以為相關的域從WHERE語句中選擇一個合適的語句key實際使用的索引。如果為NULL，則沒有使用索引。很少的情況下，MYSQL會選擇優化不足的索引。這種情況下，可以在SELECT語句中使用USEINDEX（indexname）來強制使用一個索引或者用IGNOREINDEX（indexname）來強制MYSQL忽略索引key_len使用的索引的長度。在不損失精確性的情況下，長度越短越好ref顯示索引的哪一列被使用了，如果可能的話，是一個常數rowsMYSQL認為必須檢查的用來返回請求數據的行數Extra關於MYSQL如何解析查詢的額外信息。將在表4.3中討論，但這里可以看到的壞的例子是Usingtemporary和Usingfilesort，意思MYSQL根本不能使用索引，結果是檢索會很慢extra列返回的描述的意義Distinct一旦MYSQL找到了與行相聯合匹配的行，就不再搜索了NotexistsMYSQL優化了LEFTJOIN，一旦它找到了匹配LEFTJOIN標準的行，就不再搜索了RangecheckedforeachRecord（indexmap:#）沒有找到理想的索引，因此對於從前面表中來的每一個行組合，MYSQL檢查使用哪個索引，並用它來從表中返回行。這是使用索引的最慢的連接之一Usingfilesort看到這個的時候，查詢就需要優化了。MYSQL需要進行額外的步驟來發現如何對返回的行排序。它根據連接類型以及存儲排序鍵值和匹配條件的全部行的行指針來排序全部行Usingindex列數據是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，這發生在對表的全部的請求列都是同一個索引的部分的時候Usingtemporary看到這個的時候，查詢需要優化了。這里，MYSQL需要創建一個臨時表來存儲結果，這通常發生在對不同的列集進行ORDERBY上，而不是GROUPBY上Whereused使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給用戶。如果不想返回表中的全部行，並且連接類型ALL或index，這就會發生，或者是查詢有問題不同連接類型的解釋（按照效率高低的順序排序）const表中的一個記錄的最大值能夠匹配這個查詢（索引可以是主鍵或惟一索引）。因為只有一行，這個值實際就是常數，因為MYSQL先讀這個值然後把它當做常數來對待eq_ref在連接中，MYSQL在查詢時，從前面的表中，對每一個記錄的聯合都從表中讀取一個記錄，它在查詢使用了索引為主鍵或惟一鍵的全部時使用ref這個連接類型只有在查詢使用了不是惟一或主鍵的鍵或者是這些類型的部分（比如，利用最左邊前綴）時發生。對於之前的表的每一個行聯合，全部記錄都將從表中讀出。這個類型嚴重依賴於根據索引匹配的記錄多少—越少越好range這個連接類型使用索引返回一個范圍中的行，比如使用>或<查找東西時發生的情況index這個連接類型對前面的表中的每一個記錄聯合進行完全掃描（比ALL更好，因為索引一般小於表數據）ALL這個連接類型對於前面的每一個記錄聯合進行完全掃描，這一般比較糟糕，應該盡量避免
⑵ 根據mysql慢日誌監控SQL語句執行效率
根據mysql慢日誌監控SQL語句執行效率
啟用MySQL的log-slow-queries(慢查詢記錄)。
在Linux環境下先要找到my.cnf文件(一般在/etc/mysql/)，然後可能會發現該文件修改後無法保存，原因是你沒有相應的許可權，可以從屬性中看到該文件的所有者是root，這時要先以root的身份打開它：
sudo
nautilus
/etc/mysql
接著再打開my.cnf文件然後找到[mysqld]標簽在下面加上：
log-slow-queries=/path/slow.log
–慢日誌保存路徑，該文件自己新建
long_query_time=2
–超過2秒的查詢
log-queries-not-using-indexes
–記錄沒有使用索引的查詢
保存，關閉。然後如果重啟MySQL的話會碰到這樣的提示：world-writable
config
file
『
etc
my.cnf'
is
ignored
這時需要你再運行這個代碼：
chmod
644
/etc/my.cnf
–644表示rw-r–r–
然後再重啟服務就OK了。
但是要注意的是：log-slow-queries=/path/slow.log為慢查詢日誌存放的地方，而這個目錄要有MySQL的運行帳號的可寫許可權，一般都將這個目錄設置為MySQL的數據存放目錄。
我是這么做的：先用root用戶進到MySQL的數據存放目錄(一般是/var/lib/mysql)，新建一個slow.log文件(root用戶能保證有許可權新建，再運行chmod
644)。然後更改該文件的所有者和所在組：
chown
mysql運行帳戶的名字(可以看同文件夾中其他文件的所有者和組)+小數點+組名(方法同用戶名)
/path/slow.log
或者：
chown
mysql運行帳戶的名字(可以看同文件夾中其他文件的所有者和組)
/path/slow.log
chgrp
組名(方法同用戶名)
/path/slow.log
這樣才能保證MySQL能往slow.log中寫日誌。
⑶ 壓測時在mysql慢查詢日誌中有一條很簡單的SQL語句，不知為何
這是一個慢查詢日誌的展示工具，能夠幫助 DBA 或者開發人員分析資料庫的性能問題，給出全面的數據擺脫直接查看 slow-log。QAN（Query Analytics）
PMM 目前有 2 個版本，但是對於 QAN 來說其大致由三部分組成：
QAN-Agent（client）：負責採集 slow-log 的數據並上報到服務端
QAN-API（server）：負責存儲採集的數據，並對外提供查詢介面
QAN-APP：專門用來展示慢查詢數據的 grafana 第三方插件
1. 數據流轉
slow-log --> QAN-Agent --> QAN-API <--> QAN-APP（grafana）
2. pmm1 架構圖
⑷ 如何查看sql資料庫操作日誌
請參照以下步驟查看sql資料庫操作日誌。
1、首先在電腦上打開sql server軟體，進入軟體載入界面。
⑸ mysql 很多慢日誌，怎麼解決
這是一個慢查詢日誌的展示工具，能夠幫助 DBA 或者開發人員分析資料庫的性能問題，給出全面的數據擺脫直接查看 slow-log。QAN（Query Analytics）
PMM 目前有 2 個版本，但是對於 QAN 來說其大致由三部分組成：
QAN-Agent（client）：負責採集 slow-log 的數據並上報到服務端
QAN-API（server）：負責存儲採集的數據，並對外提供查詢介面
QAN-APP：專門用來展示慢查詢數據的 grafana 第三方插件
1. 數據流轉
slow-log --> QAN-Agent --> QAN-API <--> QAN-APP（grafana）
2. pmm1 架構圖
⑹ 如何利用pt-query-digest分析慢查詢日誌top SQL
Oracle資料庫可利用awr報告來查找top sql，其實MySQL中，我們可以利用pt-query-digest工具來查找時間最長的TOP SQL。
pt-query-digest可以從普通MySQL日誌，慢查詢日誌以及二進制日誌中分析查詢，甚至可以從SHOW PROCESSLIST和MySQL協議的tcpmp中進行分析，如果沒有指定文件，它從標准輸入流（STDIN）中讀取數據。
[apps@mvxl0782 bin]$ pwd
/apps/tool/percona-toolkit-2.2.10/bin
[apps@mvxl0782 bin]$ ./pt-query-digest /apps/logs/mysql/slow3306.log
整個輸出分為三大部分：
1、整體概要（Overall）
# 8.9s user time, 50ms system time, 25.92M rss, 200.46M vsz
⑺ 如何查找MySQL中查詢慢的SQL語句
問題
我們有一個 SQL，用於找到沒有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運行特別慢，怎麼辦?
實驗
我們搭建一個 MySQL 5.7 的環境，此處省略搭建步驟。
寫個簡單的腳本，製造一批帶主鍵和不帶主鍵的表：
可以看到執行時間變成了 0.67s。
整理
我們診斷的關鍵點如下：
1. 對於 information_schema 中的元數據表，執行計劃不能提供有效信息。
2. 通過查看 MySQL 改寫後的 SQL，我們猜測了優化器發生了誤判。
3. 我們增加了 hint，指導 MySQL 正確進行優化判斷。
但目前我們的實驗僅限於猜測，猜中了萬事大吉，猜不中就無法做出好的診斷。
⑻ 記錄一次慢sql排查
mysql的慢日誌中，看到有這么一條
不算太復雜的一條sql，但是掃了200多萬行的數據，所以慢。先看執行計劃
mysql> explain SELECT
-> lu.userId,
-> lu.userName,
-> lu.photo userImage,
-> lu.sex,
-> wc.typeId AS courseType,
-> wc.name AS courseName,
-> lc.className,
-> DATE_FORMAT(wcu.CreatedTime, '%Y-%m-%d %H:%i:%s') AS time
-> FROM
-> wkt_courseclassuser wcu
-> INNER JOIN wkt_course wc on wcu.courseId = wc.id
-> INNER JOIN lxx_user lu ON wcu.userId = lu.userId
-> INNER JOIN (select t.* from (select * from lxx_classuserrecord WHERE classtypeid =1 ORDER BY CreateTime desc) t GROUP BY t.userid ) lcur ON lcur.userid = lu.userId
-> INNER JOIN lxx_class lc on lc.classId = lcur.classId
-> INNER JOIN lxx_registerschool lr ON lr.schoolKey = lu.schoolKey
-> WHERE lc.status = 1 and lc.typeId = 1
-> and lr.schoolId = 60800000000000001
-> and wc.typeId in (1,2,3,23)
-> ORDER BY wc.CreateTime DESC
-> LIMIT 100;
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+----------------------------------+---------+-------------------------+-------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+----------------------------------+---------+-------------------------+-------+----------------------------------------------+
| 1 | PRIMARY | lr | ref | lxx_registerSchool_schoolId | lxx_registerSchool_schoolId | 9 | const | 1 | Using where; Using temporary; Using filesort |
| 1 | PRIMARY | lu | ref | PRIMARY,index_lxx_user_schoolKey | index_lxx_user_schoolKey | 603 | wkt_school.lr.schoolKey | 79 | Using where |
| 1 | PRIMARY | <derived2> | ref | <auto_key1> | <auto_key1> | 8 | wkt_school.lu.userId | 15 | Using where |
| 1 | PRIMARY | lc | eq_ref | PRIMARY | PRIMARY | 8 | lcur.classid | 1 | Using where |
| 1 | PRIMARY | wcu | ref | index_wkt_courseclassuser_courseId,index_wkt_courseclassuser_userId,index_wkt_courseclassuser_courseId_classId | index_wkt_courseclassuser_userId | 9 | wkt_school.lu.userId | 47 | Using where |
| 1 | PRIMARY | wc | eq_ref | PRIMARY | PRIMARY | 8 | wkt_school.wcu.courseId | 1 | Using where |
| 2 | DERIVED | <derived3> | ALL | NULL | NULL | NULL | NULL | 47204 | Using temporary; Using filesort |
| 3 | DERIVED | lxx_classuserrecord | ALL | NULL | NULL | NULL | NULL | 47204 | Using where; Using filesort |
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+----------------------------------+---------+-------------------------+-------+----------------------------------------------+
乍一看好像最大的rows才47204，為什麼實際執行掃描行數要大這么多呢？
網上找到一篇解釋
https://dba.stackexchange.com/questions/73520/mysql-explain-has-different-row-count-than-slow-query-log
大概意思是，explain只是根據數據的特徵，大概估算要掃描的行數，實際執行時，特別是需要做join操作時，結果集都是n*m的，因此實際執行結果可能要大很多。
看到執行計劃最後兩行，都是需要Using filesort的。很明顯是產生於
INNER JOIN (select t.* from (select * from lxx_classuserrecord WHERE classtypeid =1 ORDER BY CreateTime desc) t GROUP BY t.userid ) lcur ON lcur.userid = lu.userId
一行。因為INNER JOIN的是一個子查詢的結果， 上面不會有索引 ，而且這個子查詢的結果集也有幾萬條，開始的直觀感覺是慢在這里。結果優化了很久，也沒什麼效果。最後把這個關聯條件也去掉了，發現查詢時間還是跟原來差不多，因此問題不是在此。
PS：第一次沒有看懂explain的結果。explain中的第三行從derived2的結果中，也就是id為2的那條派生表查詢中，自動建立了一個auto_key1的索引，因此inner join上面那行子查詢並不會很慢
東找西找，發現去掉ORDER BY wc.CreateTime DESC以後，就變得很快了。查看了一下wkt_course的索引，果然CreateTime沒有索引。趕緊補一下
CREATE INDEX index_wkt_course_CreateTime ON wkt_course(CreateTime)
然後再explain一下，
| 1 | PRIMARY | lr | ref | lxx_registerSchool_schoolId | lxx_registerSchool_schoolId | 9 | const | 1 | Using where; Using temporary; Using filesort |
第一行這里沒有任何改觀。實際執行起來也絲毫沒有變快。
再靜下來，仔細分析一下問題在哪裡。mysql估計是先執行了連表查詢，然後對這個結果集創建臨時表，然後進行排序，最後在取出前100。用select count(*) 在去掉limit限制後數了一下，這個結果集有80多萬條數據，怪不得排序很慢。這里總結出來一個經驗，就是看explain首先要關注Using temporary，其次是Using filesort的問題。
要使ORDER BY的欄位走索引，則需要讓欄位所在的表成為驅動表
https://blog.csdn.net/zerou8400/article/details/95389044
最終的解決方案，在order by的欄位建立索引，並且使用straight_join，強制指定wkt_course為驅動表
SELECT
lu.userId,
lu.userName,
lu.photo userImage,
lu.sex,
wc.typeId AS courseType,
wc.name AS courseName,
lc.className,
DATE_FORMAT(wcu.CreatedTime, '%Y-%m-%d %H:%i:%s') AS time
FROM
wkt_course wc
straight_join wkt_courseclassuser wcu ON wcu.courseId = wc.id
INNER JOIN lxx_user lu ON wcu.userId = lu.userId
INNER JOIN lxx_registerschool lr on lr.schoolKey = lu.schoolKey
INNER JOIN (select t.* from (select * from lxx_classuserrecord WHERE classtypeid =1 ORDER BY CreateTime desc) t GROUP BY t.userid ) lcur ON lcur.userid = lu.userId
INNER JOIN lxx_class lc on lc.classId = lcur.classId
WHERE lr.schoolId = 60800000000000001
and wc.typeId in (1,2,3,23)
and lc.status = 1 and lc.typeId = 1
ORDER BY wc.CreateTime DESC
LIMIT 100;
圍觀一下優化後的執行計劃
mysql> explain SELECT
-> lu.userId,
-> lu.userName,
-> lu.photo userImage,
-> lu.sex,
-> wc.typeId AS courseType,
-> wc.name AS courseName,
-> lc.className,
-> DATE_FORMAT(wcu.CreatedTime, '%Y-%m-%d %H:%i:%s') AS time
-> FROM
-> wkt_course wc
-> straight_join wkt_courseclassuser wcu ON wcu.courseId = wc.id
-> INNER JOIN lxx_user lu ON wcu.userId = lu.userId
-> INNER JOIN lxx_registerschool lr on lr.schoolKey = lu.schoolKey
-> INNER JOIN (select t.* from (select * from lxx_classuserrecord WHERE classtypeid =1 ORDER BY CreateTime desc) t GROUP BY t.userid ) lcur ON lcur.userid = lu.userId
-> INNER JOIN lxx_class lc on lc.classId = lcur.classId
-> WHERE lr.schoolId = 60800000000000001
-> and wc.typeId in (1,2,3,23)
-> and lc.status = 1 and lc.typeId = 1
-> ORDER BY wc.CreateTime DESC
-> LIMIT 100;
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+------------------------------------+---------+-----------------------+-------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+------------------------------------+---------+-----------------------+-------+---------------------------------+
| 1 | PRIMARY | wc | index | PRIMARY | index_wkt_course_CreateTime | 6 | NULL | 1 | Using where |
| 1 | PRIMARY | lr | ref | lxx_registerSchool_schoolId | lxx_registerSchool_schoolId | 9 | const | 1 | NULL |
| 1 | PRIMARY | wcu | ref | index_wkt_courseclassuser_courseId,index_wkt_courseclassuser_userId,index_wkt_courseclassuser_courseId_classId | index_wkt_courseclassuser_courseId | 9 | wkt_school.wc.id | 31 | Using where |
| 1 | PRIMARY | lu | eq_ref | PRIMARY,index_lxx_user_schoolKey | PRIMARY | 8 | wkt_school.wcu.userId | 1 | Using where |
| 1 | PRIMARY | <derived2> | ref | <auto_key1> | <auto_key1> | 8 | wkt_school.wcu.userId | 15 | Using where |
| 1 | PRIMARY | lc | eq_ref | PRIMARY | PRIMARY | 8 | lcur.classid | 1 | Using where |
| 2 | DERIVED | <derived3> | ALL | NULL | NULL | NULL | NULL | 36487 | Using temporary; Using filesort |
| 3 | DERIVED | lxx_classuserrecord | ALL | NULL | NULL | NULL | NULL | 36487 | Using where; Using filesort |
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+------------------------------------+---------+-----------------------+-------+---------------------------------+
https://blog.csdn.net/m0_37894254/article/details/80675733