1 概念

MySQL的慢查詢，全名是慢查詢日志，是MySQL提供的一種日志記錄，用來記錄在MySQL中響應時間超過閥值的語句。

具體環(huán)境中，運行時間超過long_query_time值的SQL語句，則會被記錄到慢查詢日志中。

long_query_time的默認值為10，意思是記錄運行10秒以上的語句。

默認情況下，MySQL數據庫并不啟動慢查詢日志，需要手動來設置這個參數。

當然，如果不是調優(yōu)需要的話，一般不建議啟動該參數，因為開啟慢查詢日志會或多或少帶來一定的性能影響。

慢查詢日志支持將日志記錄寫入文件和數據庫表。

1.1 數據庫中設置SQL慢查詢

1.1.1 第一步.開啟mysql慢查詢

• 方式一：

修改配置文件 在 my.ini 增加幾行: 主要是慢查詢的定義時間（超過2秒就是慢查詢），以及慢查詢log日志記錄（ slow_query_log）

• 方法二：通過MySQL數據庫開啟慢查詢:

  
  

1.2 分析慢查詢日志

直接分析mysql慢查詢日志 ,利用explain關鍵字可以模擬優(yōu)化器執(zhí)行SQL查詢語句，來分析sql慢查詢語句

例如：執(zhí)行EXPLAIN SELECT * FROM app_mobile_device ORDER BYmodifiedtime LIMIT 0,1000

得到如下結果： 顯示結果分析：

1.3 常見的慢查詢優(yōu)化

1.3.1 索引沒起作用的情況

• 使用LIKE關鍵字的查詢語句

在使用LIKE關鍵字進行查詢的查詢語句中，如果匹配字符串的第一個字符為“%”，索引不會起作用。只有“%”不在第一個位置索引才會起作用。

• 使用多列索引的查詢語句
  MySQL可以為多個字段創(chuàng)建索引。一個索引最多可以包括16個字段。對于多列索引，只有查詢條件使用了這些字段中的第一個字段時，索引才會被使用。

1.3.2 優(yōu)化數據庫結構

合理的數據庫結構不僅可以使數據庫占用更小的磁盤空間，而且能夠使查詢速度更快。數據庫結構的設計，需要考慮數據冗余、查詢和更新的速度、字段的數據類型是否合理等多方面的內容。

• 將字段很多的表分解成多個表

對于字段比較多的表，如果有些字段的使用頻率很低，可以將這些字段分離出來形成新表。因為當一個表的數據量很大時，會由于使用頻率低的字段的存在而變慢。

• 增加中間表

對于需要經常聯合查詢的表，可以建立中間表以提高查詢效率。通過建立中間表，把需要經常聯合查詢的數據插入到中間表中，然后將原來的聯合查詢改為對中間表的查詢，以此來提高查詢效率。

1.3.3 分解關聯查詢

將一個大的查詢分解為多個小查詢是很有必要的。

很多高性能的應用都會對關聯查詢進行分解，就是可以對每一個表進行一次單表查詢，然后將查詢結果在應用程序中進行關聯，很多場景下這樣會更高效，例如：

 SELECT * FROM tag 
        JOIN tag_post ON tag_id = tag.id
        JOIN post ON tag_post.post_id = post.id
        WHERE tag.tag = 'mysql';
 
        分解為：
 
        SELECT * FROM tag WHERE tag = 'mysql';
        SELECT * FROM tag_post WHERE tag_id = 1234;
        SELECT * FROM post WHERE post.id in (123,456,567);

1.3.4 優(yōu)化LIMIT分頁

在系統(tǒng)中需要分頁的操作通常會使用limit加上偏移量的方法實現，同時加上合適的order by 子句。如果有對應的索引，通常效率會不錯，否則MySQL需要做大量的文件排序操作。

一個非常令人頭疼問題就是當偏移量非常大的時候，例如可能是limit 10000,20這樣的查詢，這是mysql需要查詢10020條然后只返回最后20條，前面的10000條記錄都將被舍棄，這樣的代價很高。

優(yōu)化此類查詢的一個最簡單的方法是盡可能的使用索引覆蓋掃描，而不是查詢所有的列。然后根據需要做一次關聯操作再返回所需的列。對于偏移量很大的時候這樣做的效率會得到很大提升。

對于下面的查詢：

select id,title from collect limit 90000,10;

該語句存在的最大問題在于limit M,N中偏移量M太大（我們暫不考慮篩選字段上要不要添加索引的影響），導致每次查詢都要先從整個表中找到滿足條件 的前M條記錄，之后舍棄這M條記錄并從第M+1條記錄開始再依次找到N條滿足條件的記錄。如果表非常大，且篩選字段沒有合適的索引，且M特別大那么這樣的代價是非常高的。 試想，如我們下一次的查詢能從前一次查詢結束后標記的位置開始查找，找到滿足條件的100條記錄，并記下下一次查詢應該開始的位置，以便于下一次查詢能直接從該位置 開始，這樣就不必每次查詢都先從整個表中先找到滿足條件的前M條記錄，舍棄，在從M+1開始再找到100條滿足條件的記錄了。

方法一：慮篩選字段（title）上加索引
title字段加索引 （此效率如何未加驗證）

方法二：先查詢出主鍵id值
select id,title from collect where id>=(select id from collect order by id limit 90000,1) limit 10;

原理：先查詢出90000條數據對應的主鍵id的值，然后直接通過該id的值直接查詢該id后面的數據。

方法三：“關延遲聯”
如果這個表非常大，那么這個查詢可以改寫成如下的方式：

Select news.id, news.description from news inner join (select id from news order by title limit 50000,5) as myNew using(id);

這里的“關延遲聯”將大大提升查詢的效率，它讓MySQL掃描盡可能少的頁面，獲取需要的記錄后再根據關聯列回原表查詢需要的所有列。這個技術也可以用在優(yōu)化關聯查詢中的limit。

方法四：建立復合索引 acct_id和create_time
select * from acct_trans_log WHERE acct_id = 3095 order by create_time desc limit 0,10

注意sql查詢慢的原因都是:引起filesort

1.3.5 分析具體的SQL語句

** 1、兩個表選哪個為驅動表，表面是可以以數據量的大小作為依據，但是實際經驗最好交給mysql查詢優(yōu)化器自己去判斷。**

例如： select * from a where id in (select id from b );

對于這條sql語句它的執(zhí)行計劃其實并不是先查詢出b表的所有id,然后再與a表的id進行比較。
mysql會把in子查詢轉換成exists相關子查詢，所以它實際等同于這條sql語句：select * from a where exists(select * from b where b.id=a.id );

而exists相關子查詢的執(zhí)行原理是: 循環(huán)取出a表的每一條記錄與b表進行比較，比較的條件是a.id=b.id . 看a表的每條記錄的id是否在b表存在，如果存在就行返回a表的這條記錄。

exists查詢有什么弊端？
由exists執(zhí)行原理可知，a表(外表)使用不了索引，必須全表掃描，因為是拿a表的數據到b表查。而且必須得使用a表的數據到b表中查（外表到里表中），順序是固定死的。

如何優(yōu)化？
建索引。但是由上面分析可知，要建索引只能在b表的id字段建，不能在a表的id上，mysql利用不上。

這樣優(yōu)化夠了嗎？還差一些。
由于exists查詢它的執(zhí)行計劃只能拿著a表的數據到b表查（外表到里表中），雖然可以在b表的id字段建索引來提高查詢效率。
但是并不能反過來拿著b表的數據到a表查，exists子查詢的查詢順序是固定死的。

為什么要反過來？
因為首先可以肯定的是反過來的結果也是一樣的。這樣就又引出了一個更細致的疑問：在雙方兩個表的id字段上都建有索引時，到底是a表查b表的效率高，還是b表查a表的效率高？

該如何進一步優(yōu)化？
把查詢修改成inner join連接查詢：select * from a inner join b on a.id=b.id; （但是僅此還不夠，接著往下看）

為什么不用left join 和 right join？
這時候表之間的連接的順序就被固定住了，比如左連接就是必須先查左表全表掃描，然后一條一條的到另外表去查詢，右連接同理。仍然不是最好的選擇。

為什么使用inner join就可以？
inner join中的兩張表，如： a inner join b，但實際執(zhí)行的順序是跟寫法的順序沒有半毛錢關系的，最終執(zhí)行也可能會是b連接a，順序不是固定死的。如果on條件字段有索引的情況下，同樣可以使用上索引。

那我們又怎么能知道a和b什么樣的執(zhí)行順序效率更高？
你不知道，我也不知道。誰知道？mysql自己知道。讓mysql自己去判斷（查詢優(yōu)化器）。具體表的連接順序和使用索引情況，mysql查詢優(yōu)化器會對每種情況做出成本評估，最終選擇最優(yōu)的那個做為執(zhí)行計劃。

在inner join的連接中,mysql會自己評估使用a表查b表的效率高還是b表查a表高，如果兩個表都建有索引的情況下，mysql同樣會評估使用a表條件字段上的索引效率高還是b表的。

利用explain字段查看執(zhí)行時運用到的key（索引）
而我們要做的就是：把兩個表的連接條件的兩個字段都各自建立上索引，然后explain 一下，查看執(zhí)行計劃，看mysql到底利用了哪個索引，最后再把沒有使用索引的表的字段索引給去掉就行了。

2 參數詳情

MySQL 慢查詢的相關參數解釋：

slow_query_log：是否開啟慢查詢日志，1表示開啟，0表示關閉。

log-slow-queries ：舊版（5.6以下版本）MySQL數據庫慢查詢日志存儲路徑?？梢圆辉O置該參數，系統(tǒng)則會默認給一個缺省的文件host_name-slow.log

slow-query-log-file：新版（5.6及以上版本）MySQL數據庫慢查詢日志存儲路徑?？梢圆辉O置該參數，系統(tǒng)則會默認給一個缺省的文件host_name-slow.log

long_query_time：慢查詢閾值，當查詢時間多于設定的閾值時，記錄日志。

log_queries_not_using_indexes：未使用索引的查詢也被記錄到慢查詢日志中（可選項）。

log_output：日志存儲方式。log_output='FILE'表示將日志存入文件，默認值是'FILE'。log_output='TABLE'表示將日志存入數據庫。

3 配置詳情

3.1 slow_query_log

默認情況下slow_query_log的值為OFF，表示慢查詢日志是禁用的，可以通過設置slow_query_log的值來開啟，如下所示：

mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------------+
| Variable_name | Value |
+---------------------+-----------------------------------------------+
| slow_query_log | OFF |
| slow_query_log_file | /home/WDPM/MysqlData/mysql/DB-Server-slow.log |
+---------------------+-----------------------------------------------+
2 rows in set (0.00 sec)

mysql> set global slow_query_log=1;
Query OK, 0 rows affected (0.09 sec)
使用set global slow_query_log=1開啟了慢查詢日志只對當前數據庫生效，MySQL重啟后則會失效。

如果要永久生效，就必須修改配置文件my.cnf（其它系統(tǒng)變量也是如此）。

my.cnf要增加或修改參數slow_query_log 和slow_query_log_file，如下所示

slow_query_log = 1
slow_query_log_file = /tmp/mysql_slow.log
然后重啟MySQL服務器。

3.2 slow_query_log_file

這個參數用于指定慢查詢日志的存放路徑，缺省情況是host_name-slow.log文件，

mysql> show variables like 'slow_query_log_file';
+---------------------+-----------------------------------------------+
| Variable_name | Value |
+---------------------+-----------------------------------------------+
| slow_query_log_file | /home/WDPM/MysqlData/mysql/DB-Server-slow.log |
+---------------------+-----------------------------------------------+
1 row in set (0.00 sec)

3.3 long_query_time

開啟了慢查詢日志后，什么樣的SQL才會記錄到慢查詢日志里面呢？

這個是由參數long_query_time控制，默認情況下long_query_time的值為10秒，可以使用命令修改，也可以在my.cnf參數里面修改。

關于運行時間正好等于long_query_time的情況，并不會被記錄下來。

也就是說，在mysql源碼里是判斷大于long_query_time，而非大于等于。

從MySQL 5.1開始，long_query_time開始以微秒記錄SQL語句運行時間，之前僅用秒為單位記錄。

如果記錄到表里面，只會記錄整數部分，不會記錄微秒部分。

mysql> show variables like 'long_query_time%';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)

mysql> set global long_query_time=4;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'long_query_time';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)
如上所示，我修改了變量long_query_time，但是查詢變量long_query_time的值還是10，難道沒有修改到呢？

注意：使用命令 set global long_query_time=4修改后，需要重新連接或新開一個會話才能看到修改值。

用show variables like 'long_query_time'查看是當前會話的變量值。

也可以不用重新連接會話，而是用show global variables like 'long_query_time';。

3.4 log_output

log_output參數指定日志的存儲方式。

log_output='FILE'表示將日志存入文件，默認值也是'FILE'。

log_output='TABLE'表示將日志存入數據庫，這樣日志信息就會被寫入到mysql.slow_log表中。

同時也支持兩種日志存儲方式，配置的時候以逗號隔開即可，如：log_output='FILE,TABLE'。

日志記錄到系統(tǒng)的專用日志表中，要比記錄到文件耗費更多的系統(tǒng)資源。

因此對于需要啟用慢查詢日志，又需要能夠獲得更高的系統(tǒng)性能，那么建議優(yōu)先記錄到文件。

mysql> show variables like '%log_output%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_output | FILE |
+---------------+-------+
1 row in set (0.00 sec)

mysql> set global log_output='TABLE';
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%log_output%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_output | TABLE |
+---------------+-------+
1 row in set (0.00 sec)

mysql> select sleep(5) ;
+----------+
| sleep(5) |
+----------+
| 0 |
+----------+
1 row in set (5.00 sec)

mysql>

mysql> select * from mysql.slow_log;
+---------------------+---------------------------+------------+-----------+-----------+---------------+----+----------------+-----------+-----------+-----------------+-----------+
| start_time | user_host | query_time | lock_time | rows_sent | rows_examined | db | last_insert_id | insert_id | server_id | sql_text | thread_id |
+---------------------+---------------------------+------------+-----------+-----------+---------------+----+----------------+-----------+-----------+-----------------+-----------+
| 2016-06-16 17:37:53 | root[root] @ localhost [] | 00:00:03 | 00:00:00 | 1 | 0 | | 0 | 0 | 1 | select sleep(3) | 5 |
| 2016-06-16 21:45:23 | root[root] @ localhost [] | 00:00:05 | 00:00:00 | 1 | 0 | | 0 | 0 | 1 | select sleep(5) | 2 |
+---------------------+---------------------------+------------+-----------+-----------+---------------+----+----------------+-----------+-----------+-----------------+-----------+
2 rows in set (0.00 sec)

3.5 log-queries-not-using-indexes

該系統(tǒng)變量指定未使用索引的查詢也被記錄到慢查詢日志中（可選項）。

如果調優(yōu)的話，建議開啟這個選項。

另外，開啟了這個參數，其實使用full index scan的SQL也會被記錄到慢查詢日志。

mysql> show variables like 'log_queries_not_using_indexes';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | OFF |
+-------------------------------+-------+
1 row in set (0.00 sec)

mysql> set global log_queries_not_using_indexes=1;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'log_queries_not_using_indexes';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | ON |
+-------------------------------+-------+
1 row in set (0.00 sec)

3.6 log_slow_admin_statements

這個系統(tǒng)變量表示，是否將慢管理語句例如ANALYZE TABLE和ALTER TABLE等記入慢查詢日志。

mysql> show variables like 'log_slow_admin_statements';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| log_slow_admin_statements | OFF |
+---------------------------+-------+
1 row in set (0.00 sec)

3.7 Slow_queries

如果你想查詢有多少條慢查詢記錄，可以使用Slow_queries系統(tǒng)變量。

mysql> show global status like '%Slow_queries%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Slow_queries | 2104 |
+---------------+-------+
1 row in set (0.00 sec)
另外，還有l(wèi)og_slow_slave_statements 和 --log-short-format 參數，可到MySQL網站了解。

4 mysqldumpslow工具

在生產環(huán)境中，如果要手工分析日志，查找、分析SQL，顯然是個體力活。

MySQL提供了日志分析工具mysqldumpslow

查看mysqldumpslow的幫助信息：

[root@DB-Server ~]# mysqldumpslow --help
 Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]

Parse and summarize the MySQL slow query log. Options are

  --verbose    verbose
  --debug      debug
  --help       write this text to standard output

  -v           verbose
  -d           debug
  -s ORDER     what to sort by (al, at, ar, c, l, r, t), 'at' is default（排序方式）
                 al: average lock time（平均鎖定時間）
                 ar: average rows sent（平均返回記錄數）
                 at: average query time（平均查詢時間）
                  c: count（訪問計數）
                  l: lock time（鎖定時間）
                  r: rows sent（返回記錄）
                  t: query time（查詢時間）
   -r           reverse the sort order (largest last instead of first)
   -t NUM       just show the top n queries（返回前面n條數據）
   -a           don't abstract all numbers to N and strings to 'S'
   -n NUM       abstract numbers with at least n digits within names
   -g PATTERN   grep: only consider stmts that include this string（正則匹配模式，大小寫不敏感）
   -h HOSTNAME  hostname of db server for *-slow.log filename (can be wildcard),
                default is '*', i.e. match all
   -i NAME      name of server instance (if using mysql.server startup script)
   -l           don't subtract lock time from total time
 

比如，得到返回記錄集最多的10個SQL。

mysqldumpslow -s r -t 10 /database/mysql/mysql06_slow.log
得到訪問次數最多的10個SQL

mysqldumpslow -s c -t 10 /database/mysql/mysql06_slow.log
得到按照時間排序的前10條里面含有左連接的查詢語句。

mysqldumpslow -s t -t 10 -g “l(fā)eft join” /database/mysql/mysql06_slow.log
另外建議在使用這些命令時結合 | 和more 使用 ，否則有可能出現刷屏的情況。

mysqldumpslow -s r -t 20 /mysqldata/mysql/mysql06-slow.log | more