?導(dǎo)航：?
【黑馬Java筆記+踩坑匯總】JavaSE+JavaWeb+SSM+SpringBoot+瑞吉外賣+SpringCloud+黑馬旅游+谷粒商城+學(xué)成在線+設(shè)計模式+?？兔嬖囶}
目錄
1. 數(shù)據(jù)庫服務(wù)器的優(yōu)化步驟
2. 查看系統(tǒng)性能參數(shù)
2.1 SHOW STATUS LIKE '參數(shù)'
2.2?查看SQL的查詢成本
3. 定位執(zhí)行慢的 SQL：慢查詢?nèi)罩?/p>
3.0 介紹?
3.1 開啟慢查詢?nèi)罩緟?shù)
3.2 查看慢查詢次數(shù)
3.5 慢查詢?nèi)罩痉治龉ぞ撸簃ysqldumpslow
3.6 關(guān)閉慢查詢?nèi)罩?/p>
3.7 刪除慢查詢?nèi)罩?/p>
4. 定位慢查詢語句、查看 SQL 執(zhí)行成本：show profile
5. 執(zhí)行計劃表：EXPLAIN
5.1 簡介
5.2 基本語法
5.3 執(zhí)行計劃表介紹?
5.3.1 執(zhí)行計劃各個列的作用（概述）
5.3.2 詳細介紹
5.3.2.1 select_type
5.3.2.2 key
5.3.2.3 type
5.3.2.4 Extra
5.4 EXPLAIN四種輸出格式
5.5 SHOW WARNINGS的使用
6. 分析優(yōu)化器執(zhí)行計劃：trace
7. MySQL監(jiān)控分析視圖-sys schema
7.1 簡介
7.2 使用場景
1. 數(shù)據(jù)庫服務(wù)器的優(yōu)化步驟
在數(shù)據(jù)庫調(diào)優(yōu)中，我們的目標就是響應(yīng)時間更快，吞吐量更大。利用宏觀的監(jiān)控工具和微觀的日志分析可以幫我們快速找到調(diào)優(yōu)的思路和方式。?
調(diào)優(yōu)流程：
- SHOW STATUS觀察服務(wù)器狀態(tài)，是否存在周期性波動；如果存在的話就緩存優(yōu)化；
- 如果還存在不規(guī)則延遲或卡頓的話，就開啟慢查詢、explan分析查詢語句；
- 如果發(fā)現(xiàn)sql等待時間長，就調(diào)優(yōu)服務(wù)器參數(shù)；如果發(fā)現(xiàn)sql執(zhí)行時間長，就索引優(yōu)化、表優(yōu)化；
- 如果還存在不規(guī)則延遲或卡頓的話，就觀察sql查詢是否到瓶頸了；是的話就讀寫分離、分庫分表。
三種分析工具（SQL調(diào)優(yōu)三步驟）：慢查詢、EXPLAN、SHOW PROFLING?
?
整個流程劃分成了觀察（Show status） 和行動（Action） 兩個部分。字母 S 的部分代表觀察（會使用相應(yīng)的分析工具），字母 A 代表的部分是行動（對應(yīng)分析可以采取的行動）。
2. 查看系統(tǒng)性能參數(shù)
2.1 SHOW STATUS LIKE '參數(shù)'
在MySQL中，可以使用SHOW STATUS 語句查詢一些MySQL數(shù)據(jù)庫服務(wù)器的性能參數(shù)、執(zhí)行頻率。
SHOW STATUS語句語法如下：
SHOW [GLOBAL|SESSION] STATUS LIKE '參數(shù)';示例，查看數(shù)據(jù)庫連接次數(shù)和運行時長：?
??
?中括號代表可省略。
一些常用的性能參數(shù)如下：
? Connections：連接MySQL服務(wù)器的次數(shù)。
? Uptime：MySQL服務(wù)器的上線時間。重啟服務(wù)器后會重置。
? Slow_queries：慢查詢的次數(shù)。查詢時長超過指定時間，次數(shù)越少越好。
? Innodb_rows_read：Select查詢返回的行數(shù)
? Innodb_rows_inserted：執(zhí)行INSERT操作插入的行數(shù)
? Innodb_rows_updated：執(zhí)行UPDATE操作更新的行數(shù)
? Innodb_rows_deleted：執(zhí)行DELETE操作刪除的行數(shù)
? Com_select：查詢操作的次數(shù)。
? Com_insert：插入操作的次數(shù)。對于批量插入的 INSERT 操作，只累加一次。
? Com_update：更新操作的次數(shù)。
? Com_delete：刪除操作的次數(shù)。
? last_query_cost：查詢優(yōu)化器上一個查詢的成本，最近一次刪除用到數(shù)據(jù)頁數(shù)量。
2.2?查看SQL的查詢成本
SHOW STATUS LIKE 'last_query_cost';
SQL查詢是一個動態(tài)的過程，從頁加載的角度來看:
1.緩沖池查詢效率優(yōu)于從磁盤查
如果頁就在數(shù)據(jù)庫緩沖池中，那么效率是最高的，否則還需要從內(nèi)存或者磁盤中進行讀取，當然針對單個頁的讀取來說，如果頁存在于內(nèi)存中，會比在磁盤中讀取效率高很多.
MySQL的緩沖池被分為多個不同的緩存池，其中包括：
- 查詢緩存：用來緩存查詢結(jié)果。
- InnoDB緩存池：用來緩存熱點表和索引數(shù)據(jù)頁。
- MyISAM緩存池：用來緩存表數(shù)據(jù)塊。
當緩沖池中已經(jīng)存儲了較多的數(shù)據(jù)時，MySQL會使用一種叫做緩沖池替換算法的方法，將部分緩存數(shù)據(jù)替換出去，以騰出空間為新的數(shù)據(jù)做緩存。
MySQL的緩沖池使用的是LRU（最近最少使用）算法，它會優(yōu)先緩存最近使用的數(shù)據(jù)。當緩沖池的空間不足時，MySQL會將最不常用的數(shù)據(jù)從緩沖池中替換出去，以騰出空間緩存新的數(shù)據(jù)。
2.批量順序查詢平均下來每頁查詢更高
如果我們從磁盤中對單一頁進行隨機讀，那么效率是很低的(差不多10ms)，而采用順序讀取的方式，批量對頁進行讀取，平均一頁的讀取效率就會提升很多，甚至要快于單個頁面在內(nèi)存中的隨機讀取。
所以說，遇到IO并不用擔心，方法找對了，效率還是很高的。我們首先要考慮數(shù)據(jù)存放的位置，如果是經(jīng)常使用的數(shù)據(jù)就要盡量放到緩沖池中，其次我們可以充分利用磁盤的吞吐能力，一次性批量讀取數(shù)據(jù)，這樣單個頁的讀取效率也就得到了提升。?
測試緩沖池緩存已使用的表和索引到內(nèi)存中，效率高：查詢900001和?900001~9000100查詢成本差很多，查詢速度差不多
學(xué)生信息表為例：
CREATE TABLE `student_info` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `student_id` INT NOT NULL , `name` VARCHAR(20) DEFAULT NULL, `course_id` INT NOT NULL , `class_id` INT(11) DEFAULT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;如果我們想要查詢 id=900001 的記錄，然后看下查詢成本，我們可以直接在聚簇索引上進行查找：
SELECT student_id, class_id, NAME, create_time FROM student_info WHERE id = 900001;運行結(jié)果（1 條記錄，運行時間為 0.042s ）
?然后再看下查詢優(yōu)化器的成本，實際上我們只需要檢索一個頁即可：
SHOW STATUS LIKE 'last_query_cost';+-----------------+----------+ | Variable_name | Value | +-----------------+----------+ | Last_query_cost | 1.000000 | +-----------------+----------+如果我們想要查詢 id 在 900001 到 9000100 之間的學(xué)生記錄呢？
SELECT student_id, class_id, NAME, create_time FROM student_info WHERE id BETWEEN 900001 AND 900100;運行結(jié)果（100 條記錄，運行時間為 0.046s ）：
然后再看下查詢優(yōu)化器的成本，這時我們大概需要進行 20 個頁的查詢。
mysql> SHOW STATUS LIKE 'last_query_cost'; +-----------------+-----------+ | Variable_name | Value | +-----------------+-----------+ | Last_query_cost | 21.134453 | +-----------------+-----------+你能看到頁的數(shù)量是剛才的 20 倍，但是查詢的效率并沒有明顯的變化，實際上這兩個 SQL 查詢的時間基本上一樣，就是因為采用了順序讀取的方式將頁面一次性加載到緩沖池中，然后再進行查找。雖然頁數(shù)量（last_query_cost）增加了不少，但是通過緩沖池的機制，并沒有增加多少查詢時間。
為什么第二次是直接從緩沖池查？
因為mysql緩存淘汰策略lru最近最少使用，會優(yōu)先緩存最近查詢數(shù)據(jù)，優(yōu)先淘汰最近最少使用數(shù)據(jù)。
使用場景：它對于比較開銷是非常有用的，特別是我們有好幾種查詢方式可選的時候。
3. 定位執(zhí)行慢的 SQL：慢查詢?nèi)罩?/h2>
3.0 介紹?
MySQL的慢查詢?nèi)罩?，用?strong>記錄在MySQL中響應(yīng)時間超過閥值的語句，具體指運行時間超過 long-query_time值的SQL，則會被記錄到慢查詢?nèi)罩局小?long_query_time的默認值為 10，意思是運行10秒以上(不含10秒)的語句，認為是超出了我們的最大忍耐時間值。
它的主要作用是，幫助我們發(fā)現(xiàn)那些執(zhí)行時間特別長的 SOL 查詢，并且有針對性地進行優(yōu)化，從而提高系統(tǒng)的整體效率。當我們的數(shù)據(jù)庫服務(wù)器發(fā)生阻塞、運行變慢的時候，檢查一下慢查詢?nèi)罩?，找到那些慢查詢，對解決問題很有幫助。比如一條sq執(zhí)行超過5秒鐘，我們就算慢SQL，希望能收集超過5秒的sql，結(jié)合explain進行全面分析
默認情況下，MySQL數(shù)據(jù)庫 沒有開啟慢查詢?nèi)罩?，需要我們手動來設(shè)置這個參數(shù)。如果不是調(diào)優(yōu)需要的話，一般不建議啟動該參數(shù)，因為開啟慢查詢?nèi)罩緯蚨嗷蛏賻硪欢ǖ?strong>性能影響
慢查詢?nèi)罩局С謱⑷罩居涗泴懭胛募?
3.1 開啟慢查詢?nèi)罩緟?shù)
0.慢查詢是否開啟?
show variables like '%slow_query_log';
慢查詢?nèi)罩疚恢茫?/p>
show variables like '%slow_query_log%';?
?慢查詢閾值：
1. 開啟慢查詢?nèi)罩緎low_query_log
set global slow_query_log='ON';然后我們再來查看下慢查詢?nèi)罩臼欠耖_啟，以及慢查詢?nèi)罩疚募奈恢茫?/p>
你能看到這時慢查詢分析已經(jīng)開啟，同時文件保存在 /var/lib/mysql/atguigu02-slow.log 文件
中。
2. 修改慢查詢閾值long_query_time
查看慢查詢的時間閾值：
show variables like '%long_query_time%';查看全局慢查詢的時間閾值：
show global variables like '%long_query_time%';?
臨時修改慢查詢的時間閾值：?
當前會話：
set long_query_time = 1; 全局：
set global long_query_time = 1; 對于 “global” 選項，是全局級別的配置參數(shù)。它可以在 MySQL 服務(wù)器啟動時或 MySQL 安裝時在 MySQL 配置文件中設(shè)置，或者通過 SET GLOBAL 命令在運行時更改。全局級別的配置參數(shù)對所有的 MySQL 連接都有效。
永久修改（重啟數(shù)據(jù)庫后依然有效，不建議永久修改，僅在優(yōu)化時候打開，慢查詢拖性能） ：
修改my.cnf
[mysqld]
slow_query_log=ON # 開啟慢查詢?nèi)罩镜拈_關(guān)
slow_query_log_file=/var/lib/mysql/atguigu-slow.log #慢查詢?nèi)罩镜哪夸浐臀募畔?long_query_time=3 #設(shè)置慢查詢的閩值為3秒，超出此設(shè)定值的SQL即被記錄到慢查詢?nèi)罩?log_output=FILE注意：?
#測試發(fā)現(xiàn)：設(shè)置global的方式對當前session的long_query_time失效。對新連接的客戶端有效。所以可以一并 執(zhí)行下述語句 set global long_query_time = 1; #設(shè)置全局慢查詢閾值1s show global variables like '%long_query_time%'; #全局1s set long_query_time=1; show variables like '%long_query_time%'; #當前會話10s
3.2 查看慢查詢次數(shù)
查詢當前系統(tǒng)中有多少條慢查詢記錄
SHOW GLOBAL STATUS LIKE '%Slow_queries%';3.5 慢查詢?nèi)罩痉治龉ぞ撸簃ysqldumpslow
`mysqldumpslow`是一個用于分析MySQL慢查詢?nèi)罩镜拿钚泄ぞ?。通過解析慢查詢?nèi)罩荆梢粤私獾綌?shù)據(jù)庫的性能問題，從而進行優(yōu)化。
查看mysqldumpslow的幫助信息
mysqldumpslow --help
mysqldumpslow 命令的具體參數(shù)如下：
-a: 不將數(shù)字抽象成N，字符串抽象成S
-s: 是表示按照何種方式排序：
- c: 訪問次數(shù)
- l: 鎖定時間
- r: 返回記錄
- t: 查詢時間
- al:平均鎖定時間
- ar:平均返回記錄數(shù)
- at:平均查詢時間 （默認方式）
- ac:平均查詢次數(shù)
-t: 即為返回前面多少條的數(shù)據(jù)；
-g: 后邊搭配一個正則匹配模式，大小寫不敏感的；
案例：
舉例：按照查詢時間排序，查看前五條 慢查詢SQL 語句，這樣寫即可：
mysqldumpslow -s t -t 5 /var/lib/mysql/atguigu01-slow.log
舉例，假設(shè)想查看最慢的10個查詢，可以使用如下命令：
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log這條命令表示按照時間排序，顯示最慢的10個查詢，/var/log/mysql/mysql-slow.log是MySQL慢查詢?nèi)罩镜穆窂健?/p>
另外，如果需要篩選特定的查詢，可以使用 `-g` 參數(shù)，比如：
mysqldumpslow -s t -t 10 -g "SELECT * FROM user" /var/log/mysql/mysql-slow.log這條命令表示按照時間排序，顯示最慢的10個查詢，其中關(guān)鍵字為 "SELECT * FROM user"。
總的來說，`mysqldumpslow` 命令提供了一種簡單快捷的方式幫助開發(fā)人員、DBA等分析MySQL慢查詢問題，優(yōu)化數(shù)據(jù)庫的性能。
?其他常用案例：
#得到返回記錄集最多的10個SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log
#得到訪問次數(shù)最多的10個SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/atguigu-slow.log
#得到按照時間排序的前10條里面含有左連接的查詢語句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/atguigu-slow.log
#另外建議在使用這些命令時結(jié)合 | 和more 使用 ，否則有可能出現(xiàn)爆屏情況
mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log | more
3.6 關(guān)閉慢查詢?nèi)罩?/h3>
MySQL服務(wù)器停止慢查詢?nèi)罩竟δ苡袃煞N方法：
方式1：永久性方式
[mysqld]
slow_query_log=OFF
mysql默認關(guān)閉慢查詢?nèi)罩?/strong>，或者，把slow_query_log一項注釋掉 或 刪除
[mysqld]
#slow_query_log =OFF
重啟MySQL服務(wù)，執(zhí)行如下語句查詢慢日志功能。
SHOW VARIABLES LIKE '%slow%'; #查詢慢查詢?nèi)罩舅谀夸?SHOW VARIABLES LIKE '%long_query_time%'; #查詢超時時長
方式2：臨時性方式
使用SET語句來設(shè)置。
停止MySQL慢查詢?nèi)罩竟δ?，具體SQL語句如下。
SET GLOBAL slow_query_log=off;
golbal全局有效。
重啟MySQL服務(wù)，使用SHOW語句查詢慢查詢?nèi)罩竟δ苄畔?，發(fā)現(xiàn)慢查詢?nèi)罩疽呀?jīng)關(guān)閉成功。
SHOW VARIABLES LIKE '%slow%'; #發(fā)現(xiàn)關(guān)閉成功 #慢查詢閾值 SHOW VARIABLES LIKE '%long_query_time%'; #10s。前面改的時候沒有加global，所以重啟服務(wù)器后閾值恢復(fù)10s。
3.7 刪除慢查詢?nèi)罩?/h3>
手動刪除?
使用SHOW語句顯示慢查詢?nèi)罩拘畔?，具體SQL語句如下。
SHOW VARIABLES LIKE `slow_query_log%`;
從執(zhí)行結(jié)果可以看出，慢查詢?nèi)罩镜哪夸浤J為MySQL的數(shù)據(jù)目錄，在該目錄下 手動刪除慢查詢?nèi)罩疚募?即可。
自動刪除?
使用命令 mysqladmin flush-logs?來重新生成查詢?nèi)罩疚募?，?zhí)行完畢會在數(shù)據(jù)目錄下重新生成慢查詢?nèi)罩疚募?/p>
重新生成慢查詢?nèi)罩疚募ㄖ苯觿h除舊的）
mysqladmin -uroot -p flush-logs slow
提示
慢查詢?nèi)罩径际鞘褂胢ysqladmin flush-logs命令來刪除重建的。使用時一定要注意，一旦執(zhí)行了這個命令，慢查詢?nèi)罩径贾淮嬖谛碌娜罩疚募?，如果需要舊的查詢?nèi)罩?，就必須事先備份?/p>
4. 定位慢查詢語句、查看 SQL 執(zhí)行成本：show profile
show profile 是 MySQL 提供的可以用來分析當前會話中 SQL 都做了什么、執(zhí)行的資源消耗工具的情況，可用于 sql 調(diào)優(yōu)的測量。默認情況下處于關(guān)閉狀態(tài)，并保存最近15次的運行結(jié)果。
SHOW PROFILE?是一個用于查看會話執(zhí)行的查詢的性能分析信息的 MySQL 命令。它可以幫助開發(fā)人員和 DBA 分析查詢語句執(zhí)行時的瓶頸，并找出哪些部分需要優(yōu)化。?
查看配置是否開啟profile：?
mysql > show variables like 'profiling';
- SHOW VARIABLES?顯示了 MySQL 服務(wù)器的當前配置變量，包括全局配置變量和會話配置變量，以及它們的值。SHOW VARIABLES?用于查看 MySQL 配置系統(tǒng)參數(shù)的詳細信息并進行系統(tǒng)參數(shù)的修改。
- SHOW STATUS?顯示服務(wù)器的性能參數(shù)，包括連接、線程、查詢等方面的狀態(tài)信息，以及它們的值。?
開啟 show profile:
mysql > set profiling = 'ON';
?然后執(zhí)行相關(guān)的查詢語句:
select * from employeesshow profiles; 查詢當前會話所有查詢語句持續(xù)時間
mysql > show profiles;
?show profile;查詢當前會話最近sql語句的執(zhí)行成本：
你能看到當前會話一共有 2 個查詢。如果我們想要查看最近一次查詢的開銷，可以使用：
mysql > show profile;
show profile cpu for 2;查詢指定QueryID的cpu信息：
可以查看指定的 QueryID 的開銷，比如 show profile for query 2 。在SHOW?PROFILE 中可以查看不同部分的開銷，比如 cpu、block.io 等:
mysql> show profile cpu,block io for query 2
?show profile的常用查詢參數(shù)：
① ALL：顯示所有的開銷信息。
② BLOCK IO：顯示塊IO開銷。
③ CONTEXT SWITCHES：上下文切換開銷。
④ CPU：顯示CPU開銷信息。
⑤ IPC：顯示發(fā)送和接收開銷信息。
⑥ MEMORY：顯示內(nèi)存開銷信 息。
⑦ PAGE FAULTS：顯示頁面錯誤開銷信息。
⑧ SOURCE：顯示和Source_function，Source_file， Source_line相關(guān)的開銷信息。
⑨ SWAPS：顯示交換次數(shù)開銷信息。
日常開發(fā)需注意：
① converting HEAP to MyISAM: 查詢結(jié)果太大，內(nèi)存不夠，數(shù)據(jù)往磁盤上搬了。
② Creating tmp table：創(chuàng)建臨時表。先拷貝數(shù)據(jù)到臨時表，用完后再刪除臨時表。
③ Copying to tmp table on disk：把內(nèi)存中臨時表復(fù)制到磁盤上，警惕！
④ locked。
如果在show profile診斷結(jié)果中出現(xiàn)了以上4條結(jié)果中的任何一條，則sql語句需要優(yōu)化。
注意：
不過SHOW PROFILE命令將被棄用，我們可以從 information_schema 中的 profiling 數(shù)據(jù)表進行查看。
5. 執(zhí)行計劃表：EXPLAIN
5.1 簡介
MySQL的EXPLAIN是一種分析SQL語句查詢性能的工具。當我們在MySQL中執(zhí)行SELECT語句時，EXPLAIN可以幫助我們查看MySQL如何執(zhí)行這個查詢，即執(zhí)行計劃，包括使用哪些索引、選擇哪些表、以及如何讀取數(shù)據(jù)等信息。通過分析EXPLAIN的輸出結(jié)果，我們可以更好地優(yōu)化查詢語句，提高查詢效率。
EXPLAIN的使用方式非常簡單，只需要在執(zhí)行SELECT語句時在前面加上EXPLAIN關(guān)鍵字即可，例如：
EXPLAIN SELECT * FROM my_table WHERE my_column = 'my_value';執(zhí)行以上命令后，MySQL會返回一張查詢執(zhí)行計劃表，其中包含了MySQL執(zhí)行這個查詢的詳細信息。我們可以通過分析查詢執(zhí)行計劃表來了解查詢的性能瓶頸，以及如何優(yōu)化查詢語句，從而提高查詢性能。 ?
注意：?
-
EXPLAIN不考慮各種Cache
-
EXPLAIN不能顯示MySQL在執(zhí)行查詢時所作的優(yōu)化工作
-
EXPLAIN不會告訴你關(guān)于觸發(fā)器、存儲過程的信息或用戶自定義函數(shù)對查詢的影響情況
-
部分統(tǒng)計信息是估算的，并非精確值
上一步用show profile定位了查詢慢的 SQL 之后，我們就可以使用 EXPLAIN 或 DESCRIBE 工具做針對性的分析查詢語句。DESCRIBE語句的使用方法與EXPLAIN語句是一樣的，并且分析結(jié)果也是一樣的。
MySQL中有專門負責優(yōu)化SELECT語句的優(yōu)化器模塊，主要功能: 通過計算分析系統(tǒng)中收集到的統(tǒng)計信息，為客戶端請求的Query提供它認為最優(yōu)的 執(zhí)行計劃 (他認為最優(yōu)的數(shù)據(jù)檢索方式，但不見得是DBA（數(shù)據(jù)庫管理員）認為是最優(yōu)的，這部分最耗費時間)。
這個執(zhí)行計劃展示了接下來具體執(zhí)行查詢的方式，比如多表連接的順序是什么，對于每個表采用什么訪問方法來具體執(zhí)行查詢等等。MySOL為我們提供了 EXPLAIN 語句來幫助我們查看某個查詢語句的具體執(zhí)行計劃，大家看懂EXPLAIN 語句的各個輸出項，可以有針對性的提升我們查詢語句的性能。?
1. 能做什么？
- 表的讀取順序
- 數(shù)據(jù)讀取操作的操作類型
- 哪些索引可以使用
- 哪些索引被實際使用
- 表之間的引用
- 每張表有多少行被優(yōu)化器查詢
2. 官網(wǎng)介紹
MySQL :: MySQL 5.7 Reference Manual :: 8.8.2 EXPLAIN Output Format
MySQL :: MySQL 8.0 Reference Manual :: 8.8.2 EXPLAIN Output Format
3. 版本情況
- MySQL 5.6.3以前只能 EXPLAIN SELECT ；MYSQL 5.6.3以后就可以 EXPLAIN SELECT，UPDATE， DELETE
- 在5.7以前的版本中，想要顯示 partitions 需要使用 explain partitions 命令；想要顯示 filtered 需要使用 explain extended 命令。在5.7版本后，默認explain直接顯示partitions和 filtered中的信息。
5.2 基本語法
EXPLAIN 或 DESCRIBE語句的語法形式如下：
EXPLAIN SELECT select_options
#一般指定在查詢時不使用緩存
EXPLAIN SELECT SQL_NO_CACHE select_options
#或者
DESCRIBE SELECT select_options
如果我們想看看某個查詢的執(zhí)行計劃的話，可以在具體的查詢語句前邊加一個 EXPLAIN ，就像這樣：
EXPLAIN SELECT SQL_NO_CACHE * FROM course_base;
輸出的上述信息就是所謂的 執(zhí)行計劃。在這個執(zhí)行計劃的輔助下，我們需要知道應(yīng)該怎樣改進自己的查詢語句以使查詢執(zhí)行起來更高效。其實除了以 SELECT 開頭的查詢語句，其余的 DELETE、INSERT、REPLACE 以及UPDATE 語句等都可以加上EXPLAIN，用來查看這些語句的執(zhí)行計劃，只是平時我們對 SELECT 語句更感興趣??
5.3 執(zhí)行計劃表介紹?
5.3.1 執(zhí)行計劃各個列的作用（概述）
| id | 每個SELECT子句或者join操作都會被分配一個唯一的編號，編號越小優(yōu)先級越高，id相同的語句可以被認為是一組。id為NULL表示獨立的子查詢，子查詢優(yōu)先級都比主查詢高。 |
| select_type | 查詢的類型。主查詢(primary)、普通查詢(simple)、聯(lián)合查詢、子查詢(subquery)、derived(from表臨時子查詢)、union(union后查詢)、union result() |
| table | 表名。顯示當前這行的數(shù)據(jù)是哪個表的。 |
| partitions | 匹配的分區(qū)信息。如果表未分區(qū)則為NULL。 |
| type | 訪問類型，根據(jù)索引、全表掃描等方法來執(zhí)行查詢的優(yōu)化策略。all（全表掃描），ref（命中非唯一索引），index(沒命中索引，掃描索引樹再回表)、const（命中主鍵/唯一索引）、range(范圍索引查詢)、index_merge(使用多個索引)、?system(一行記錄時,快速查詢)。 |
| possible_keys | 可能用到的索引。列出MySQL能夠使用哪些索引來查詢。 如果該列只有一個possible_keys，通常意味著這個查詢是高效的。 如果這個列有多個possible_keys，并且MySQL只使用了其中一個，則需要考慮是否需要在該列上增加一個聯(lián)合索引。 |
| key | 實際上使用的索引。如果沒有明確的指定KEY，MySQL會根據(jù)查詢條件自動選擇最優(yōu)的索引。 |
| key_len | 實際使用到索引的字節(jié)數(shù)長度。越短表示越快，一般表示索引字段越小越好。 |
| ref | 當使用索引列等值查詢時，與索引列進行等值匹配的對象信息。常量等值查詢const, 表達式/函數(shù)使用到時func,關(guān)聯(lián)查詢顯示關(guān)聯(lián)字段名 |
| rows | 預(yù)估的需要讀取的記錄條數(shù)。數(shù)值越小越好，表示結(jié)果集越小，查詢越高效。 |
| filtered | 某個表經(jīng)過搜索條件過濾后剩余記錄條數(shù)的百分比。這個值越小越好，說明可通過索引直接返回數(shù)據(jù)。 |
| Extra | 額外信息?？从袥]有走索引，還是全表掃描了。一般搭配type字段看。Using index(使用到覆蓋索引)、Using where(未完全命中索引)、Using temporary(臨時表存儲結(jié)果集.排序/分組會使用)、Using filesort(排序操作未用索引)、Using join buffer(連接條件未用索引)、Impossible where(where約束語句可能有問題導(dǎo)致沒有結(jié)果集) |
5.3.2 詳細介紹
5.3.2.1 select_type
select_type：查詢的類型，有以下幾種取值：
- SIMPLE：不使用子查詢或UNION，不包含UNION ALL的簡單SELECT查詢。
- PRIMARY：最外層的SELECT查詢。
- DERIVED：以FROM子句中的子查詢方式出現(xiàn)的SELECT語句。
- UNION：UNION中的第二個或之后的SELECT查詢。
- UNION RESULT：從UNION的結(jié)果集中獲取數(shù)據(jù)的SELECT查詢。
- SUBQUERY：不在FROM子句中出現(xiàn)的子查詢，通常在SELECT語句中使用。
- DEPENDENT SUBQUERY：子查詢依賴外層查詢的結(jié)果集。
5.3.2.2 key
key：實際上使用的索引。在MySQL中創(chuàng)建索引時使用的是INDEX關(guān)鍵字，但在EXPLAIN執(zhí)行計劃表中，顯示的是KEY，這是因為MySQL允許在創(chuàng)建索引時指定統(tǒng)計信息，例如最小值、最大值等，這些統(tǒng)計信息在索引中被視為索引鍵（Index key），所以在執(zhí)行計劃表中，顯示為KEY。
5.3.2.3 type
type：訪問類型，根據(jù)索引、全表掃描等方法來執(zhí)行查詢的優(yōu)化策略。當 type 列的取值不是 Const 時，我們需要重點關(guān)注有關(guān)索引、緩存的性能調(diào)優(yōu)，對 SQL 語句進行優(yōu)化，適當修復(fù)可能的數(shù)據(jù)設(shè)計問題。
- system：一行記錄時,快速查詢。只有一行數(shù)據(jù)即將被查詢。這是最快的查詢類型，通常出現(xiàn)在系統(tǒng)表的查詢中。
- const：命中主鍵或唯一索引。使用主鍵或唯一索引查找單個行時使用，此時查詢只能返回一行數(shù)據(jù)。這是一種非?？斓牟樵冾愋?。
- eq_ref：連接使用唯一索引查找符合查詢條件的數(shù)據(jù)時使用，每個連接類型都需要使用唯一索引進行訪問，比ref執(zhí)行速度更快。
- ref：命中非唯一索引。使用非唯一索引查找數(shù)據(jù)時使用，查詢結(jié)果比eq_ref大，但仍很快。
- range：范圍索引查詢。使用索引范圍查找數(shù)據(jù)時使用，可能會查找一定范圍內(nèi)的數(shù)據(jù)，如使用 BETWEEN 或 > 或 > < 等操作時的查詢。
-
index：沒命中索引，掃描非聚簇索引樹再回表。
- 直接在某個索引樹上做條件判斷，并且不需要回表。全表掃描沒有好的索引適用時使用，相比于全表掃描速度更快。
- index是另外一種形式的全表掃描，掃描已有索引樹然后回表取數(shù)據(jù)。和all相比，他要回表隨機取數(shù)據(jù)，因此index不可能會比all快（取同一個表數(shù)據(jù)），官方手冊說它的效率說的比all好，唯一可能的原因在于，按照索引掃描全表的數(shù)據(jù)是有序的。這樣一來，結(jié)果不同，也就沒法比效率的問題了。
- 比如：select t3.key1 from t3 where t3.key2 =6 ;當我們創(chuàng)建了聯(lián)合索引idx_key1_key2(key1,key2)時，判斷條件key2=6時，其雖然不滿足索引的最左前綴原則，但是我們可以遍歷idx_key1_key2這顆索引樹，找到key2=6的記錄即可。由于查詢結(jié)果需要的key1在這個聯(lián)合索引上，也不需要回表，此時就可以使用index。
- all：全表掃描。掃描整個表以獲得需要的數(shù)據(jù)，速度最慢，必須盡量避免使用。
- unique_subquery：在對查詢結(jié)果進行過濾或使用 IN 操作時，優(yōu)化器會選擇使用此類型的查詢，使用了 In 操作符的子查詢依賴于外層查詢的唯一索引。
- index_subquery：使用了 In 操作符但子查詢使用的普通索引，而不是唯一索引。
- range_check：在使用索引來檢查外鍵參照時使用。
- index_merge：使用多個索引。
5.3.2.4 Extra
- using index：使用了覆蓋索引，即不需要回表。查詢的幾個列正好都在這個聚簇索引樹上。覆蓋索引參考：MySQL高級篇——覆蓋索引、前綴索引、索引下推、SQL優(yōu)化、主鍵設(shè)計_mysql前綴索引-CSDN博客
- Using where：通過where過濾。沒完全命中索引，需要回表。例如index(a)，查的是where a=2 and b=3，查b=3時就要回表過濾。
- Using index condition：使用了索引下推。
- Using temporary：臨時表存儲結(jié)果集.排序/分組會使用
- Using filesort：排序操作未用索引
- Using join buffer：連接條件未用索引
- Impossible where：where約束語句可能有問題導(dǎo)致沒有結(jié)果集
5.4 EXPLAIN四種輸出格式
這里談?wù)凟XPLAIN的輸出格式。EXPLAIN可以輸出四種格式： 傳統(tǒng)格式 ，JSON格式 ， TREE格式 以及 可視化輸出 。用戶可以根據(jù)需要選擇適用于自己的格式。
1. 傳統(tǒng)格式
傳統(tǒng)格式簡單明了，輸出是一個表格形式，概要說明查詢計劃。
mysql> EXPLAIN SELECT s1.key1, s2.key1 FROM s1 LEFT JOIN s2 ON s1.key1 = s2.key1 WHERE s2.common_field IS NOT NULL;
2. JSON格式
第1種格式中介紹的EXPLAIN語句輸出中缺少了一個衡量執(zhí)行好壞的重要屬性 —— 成本。而JSON格式是四種格式里面輸出信息最詳盡的格式，里面包含了執(zhí)行的成本信息。
- JSON格式：在EXPLAIN單詞和真正的查詢語句中間加上 FORMAT=JSON 。
EXPLAIN FORMAT=JSON SELECT ....
- id：查詢所對應(yīng)的唯一標識符（id）
- select_type：查詢類型（type）
- table：正在訪問的表（table_name）
- partitions：正在訪問的分區(qū)（partition_name）
- type：使用的訪問方法（access_type）
- possible_keys：可能使用的索引（possible_keys）
- key：實際使用的索引（key）
- key_len：索引長度（key_length）
- ref：與索引匹配的列或常數(shù)（ref）
- rows：估計的檢索行數(shù)（rows）
- filtered：使用WHERE篩選后，剩余行數(shù)的百分比（filtered）
- Extra：其他信息（extra）
3. TREE格式
TREE格式是8.0.16版本之后引入的新格式，主要根據(jù)查詢的 各個部分之間的關(guān)系 和 各部分的執(zhí)行順序 來描述如何查詢。
mysql> EXPLAIN FORMAT=tree SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE
s1.common_field = 'a'\G
*************************** 1. row ***************************
EXPLAIN: -> Nested loop inner join (cost=1360.08 rows=990)
-> Filter: ((s1.common_field = 'a') and (s1.key1 is not null)) (cost=1013.75
rows=990)
-> Table scan on s1 (cost=1013.75 rows=9895)
-> Single-row index lookup on s2 using idx_key2 (key2=s1.key1), with index
condition: (cast(s1.key1 as double) = cast(s2.key2 as double)) (cost=0.25 rows=1)
1 row in set, 1 warning (0.00 sec)
4. 可視化輸出
可視化輸出，可以通過MySQL Workbench可視化查看MySQL的執(zhí)行計劃。通過點擊Workbench的放大鏡圖標，即可生成可視化的查詢計劃。
3. TREE格式
TREE格式是8.0.16版本之后引入的新格式，主要根據(jù)查詢的 各個部分之間的關(guān)系 和 各部分的執(zhí)行順序 來描述如何查詢。
mysql> EXPLAIN FORMAT=tree SELECT * FROM s1 INNER JOIN s2 ON s1.key1 = s2.key2 WHERE
s1.common_field = 'a'\G
*************************** 1. row ***************************
EXPLAIN: -> Nested loop inner join (cost=1360.08 rows=990)
-> Filter: ((s1.common_field = 'a') and (s1.key1 is not null)) (cost=1013.75
rows=990)
-> Table scan on s1 (cost=1013.75 rows=9895)
-> Single-row index lookup on s2 using idx_key2 (key2=s1.key1), with index
condition: (cast(s1.key1 as double) = cast(s2.key2 as double)) (cost=0.25 rows=1)
1 row in set, 1 warning (0.00 sec)
4. 可視化輸出
可視化輸出，可以通過MySQL Workbench可視化查看MySQL的執(zhí)行計劃。通過點擊Workbench的放大鏡圖標，即可生成可視化的查詢計劃。
上圖按從左到右的連接順序顯示表。紅色框表示 `全表掃描` ，而綠色框表示使用 `索引查找` 。對于每個表， 顯示使用的索引。還要注意的是，每個表格的框上方是每個表訪問所發(fā)現(xiàn)的行數(shù)的估計值以及訪問該表的成本。?
5.6 自測練習(xí)
5.6.1 練習(xí)題和答案解析
看不懂看參考：
MySQL高級篇——性能分析工具_mysql分析工具-CSDN博客?
假設(shè)：表a,b,c,d四個字段，創(chuàng)建索引(a),(b),(c),(a,b),(a,c)(a,b,c)
explain select * from test + 下面條件| Where語句 | 索引是否被使用 | 使用到哪些列 |
|---|---|---|
| where a = 3 | Y。命中非唯一索引。 如果是select a，則命中覆蓋索引 |
a, b, c |
| where a = 3 and b =5 | Y。命中非唯一索引。 如果是select a,b，則命中覆蓋索引 |
a, b, c |
| where a = 3 and b = 5 and c =4 | Y。命中非唯一索引。 如果是select a,b,c，則命中覆蓋索引 |
a, b, c |
| where b=3 | N。不符合最佳左前綴原則 | |
| where b=3 and c= 4 | Y。沒完全命中索引，即using where | b |
| where d = 4 | N。沒命中索引，不符合最佳左前綴原則 | |
| where c = 3 and d =5 | Y。沒完全命中索引 | c |
| where a = 3 and b> 4 and c= 5 | Y。范圍查詢+索引下推 （idx_abc樹上a精準,b范圍過濾后條件判斷c， 然后回表查a,b,c,d） |
a, b, c |
| where a is null and b is not null | Y。索引下推。如果是select a,b,c,， 則Using where; Using index，沒完全命中索引， is not null導(dǎo)致索引失效 |
a, b, c |
| where a <>3 | N。全表掃描。 沒覆蓋索引時，不等于導(dǎo)致索引失效 |
|
| where abs(a)=3 | N。全表掃描。函數(shù)導(dǎo)致索引失效 | |
| b改為varchar類型后： where a =3 and b like 'kk%' and c=4 |
Y。范圍查詢+索引下推 | a, b, c |
| where a = 3 and b like 'kk' and c = 4 |
Y。索引下推。 注意like后沒有通配符所以不是范圍查詢 |
a, b, c |
| where a = 3 and b like '%kk%' and c= 4 | Y。索引下推。如果是select a,b,c,， 則Using where; Using index，沒完全命中索引， 左模糊查詢導(dǎo)致索引失效。 |
a, b, c |
| where a = 3 and b like 'k%kk%' | Y。索引下推。 | a, b, c |
5.6.2 驗證
5.6.2.1 準備數(shù)據(jù)?
準備表和數(shù)據(jù)：?
-- 刪除test表（如果存在）
DROP TABLE IF EXISTS test;
-- 創(chuàng)建test表
CREATE TABLE test (
id INT PRIMARY KEY AUTO_INCREMENT,
a INT,
b INT,
c INT,
d INT
);
-- 插入20條數(shù)據(jù)
INSERT INTO test (a, b, c, d) VALUES
(1, 10, 100, 1000),
(2, 20, 200, 2000),
(3, 30, 300, 3000),
(4, 40, 400, 4000),
(5, 50, 500, 5000),
(6, 60, 600, 6000),
(7, 70, 700, 7000),
(8, 80, 800, 8000),
(9, 90, 900, 9000),
(10, 100, 1000, 10000),
(11, 110, 1100, 11000),
(12, 120, 1200, 12000),
(13, 130, 1300, 13000),
(14, 140, 1400, 14000),
(15, 150, 1500, 15000),
(16, 160, 1600, 16000),
(17, 170, 1700, 17000),
(18, 180, 1800, 18000),
(19, 190, 1900, 19000),
(20, 200, 2000, 20000);
創(chuàng)建索引：
-- 創(chuàng)建單列索引
CREATE INDEX idx_a ON test(a);
CREATE INDEX idx_b ON test(b);
CREATE INDEX idx_c ON test(c);
-- 創(chuàng)建復(fù)合索引
CREATE INDEX idx_a_b ON test(a, b);
CREATE INDEX idx_a_c ON test(a, c);
CREATE INDEX idx_a_b_c ON test(a, b, c);
查看所有索引：
SHOW INDEX FROM test;5.6.2.2 測試1：命中覆蓋索引
EXPLAIN SELECT
a,b,c
FROM
test
WHERE
a = 3
AND b = 5
AND c =4
解讀：
- ref：命中了非唯一索引；
- using index：使用了覆蓋索引，即不需要回表；
- key是idx_a_b_c：命中了idx_a_b_c這個索引
5.6.2.3 測試2：命中索引，需要回表
EXPLAIN SELECT
*
FROM
test
WHERE
a = 3
AND b = 5
AND c =4
解讀：
- ref：命中了非唯一索引；
- key是idx_a_b_c：命中了idx_a_b_c這個索引
?
5.5 SHOW WARNINGS的使用
在MySQL中，SHOW WARNINGS是一個可以查看最近一次執(zhí)行的語句中產(chǎn)生的警告信息的命令。當MySQL執(zhí)行語句時，如果發(fā)現(xiàn)一些不符合預(yù)期的情況，會產(chǎn)生一些警告信息。這些警告信息可以包括非致命性錯誤，例如某些類型的數(shù)據(jù)不能隱式轉(zhuǎn)換或某些數(shù)據(jù)截斷等。
當我們執(zhí)行SHOW WARNINGS命令時，MySQL會返回警告信息的詳細列表，包括：
- Warning：該警告的類型
- Level：該警告的級別，通常為Note、Warning或Error
- Code：警告的返回代碼
- Message：警告信息的內(nèi)容
可以使用SELECT的方式來查看最近一次操作的警告信息：
SHOW WARNINGS;
也可以配合使用INSERT、UPDATE、DELETE、ALTER TABLE等命令，檢查某個具體操作產(chǎn)生的警告信息：
INSERT INTO my_table (name, age) VALUES ('John Doe', 150);
SHOW WARNINGS;
在開發(fā)和調(diào)試的過程中，SHOW WARNINGS對于定位和解決某些問題非常有用，例如數(shù)據(jù)截斷、類型轉(zhuǎn)換等問題。
6. 分析優(yōu)化器執(zhí)行計劃：trace
在MySQL中，可以使用trace命令來進行優(yōu)化器執(zhí)行計劃的跟蹤和分析。trace命令可以顯示MySQL優(yōu)化器在生成執(zhí)行計劃時所采取的決策，包括哪些表被處理，以及使用哪些索引、算法等。
使用trace命令需要先啟用general_log和performance_schema兩個系統(tǒng)變量，其次需要使用SET語句來設(shè)置一些參數(shù)，例如trace-unique-check、trace-max-protocol、trace-protocol、trace-feature、trace-feature-check等。設(shè)置完成后，可以通過SET global trace_format='json'語句來選擇輸出結(jié)果的格式。
下面是對使用trace命令的一個簡單示例：
首先，設(shè)置參數(shù)：
SET @trace_feature = 'qa';
SET @max_execution_time=50000;
SET @trace_level = '+ddl,+engine';
SET @trace_feature_check = 1;
SET @trace_unique_check = 1;
SET @trace_protocol = 1;
SET @trace_max_protocol = 6;
然后，啟用general_log和performance_schema：
SET global general_log = on;
SET global performance_schema = on;
接著，執(zhí)行查詢并查看結(jié)果：
SELECT *
FROM my_table
WHERE my_column = 'some_value';
SHOW SESSION STATUS LIKE 'Last_Query_Plan';
最后，關(guān)閉general_log和performance_schema：
SET global general_log = off;
SET global performance_schema = off;
在trace輸出中，我們可以看到優(yōu)化器在執(zhí)行計劃中使用的索引、執(zhí)行算法、行數(shù)估計等細節(jié)信息。通過分析trace結(jié)果，我們可以找到一些性能問題的根源，并進行相應(yīng)的調(diào)整和優(yōu)化。但要注意，trace命令可能會帶來額外的性能消耗和IO開銷，不應(yīng)該在生產(chǎn)環(huán)境中長期啟用。
7. MySQL監(jiān)控分析視圖-sys schema
7.1 簡介
MySQL在8.0版本引入了sys schema，該模式包含用于監(jiān)視和分析MySQL服務(wù)器性能的視圖和函數(shù)。sys schema提供了一組易于使用的視圖和函數(shù)，可以幫助我們更好地理解和分析MySQL數(shù)據(jù)庫的行為和性能。
以下是sys schema中一些常用的監(jiān)控分析視圖：
- sys.statements_with_sorting: 顯示哪些語句使用了排序操作，包括使用哪些排序操作、每個語句排序的次數(shù)以及排序操作的資源消耗。
- sys.statements_with_runtimes_in_95th_percentile: 顯示執(zhí)行時間最長的語句。
- sys.io_global_by_file_by_bytes: 顯示每個文件的磁盤IO字節(jié)數(shù)，可以用來檢測IO瓶頸。
- sys.memory_by_host_by_current_bytes: 顯示每個客戶端的當前內(nèi)存使用情況，可以用于檢測內(nèi)存泄漏或內(nèi)存占用高的情況。
- sys.waits_global_by_latency: 顯示哪些等待操作最耗費時間，可以幫助我們找到性能問題的瓶頸所在。
- sys.processlist: 顯示當前正在運行的線程和進程的信息，包括執(zhí)行的語句、查詢ID、用戶、主機、線程ID和狀態(tài)等信息。
總的來說，sys schema中包含的視圖和函數(shù)為我們提供了更深入的MySQL性能分析和監(jiān)控功能，可以幫助我們更好地理解MySQL數(shù)據(jù)庫的行為和性能瓶頸。?
- 主機相關(guān)：以host_summary開頭，主要匯總了IO延遲的信息。
- Innodb相關(guān)：以innodb開頭，匯總了innodb buffer信息和事務(wù)等待innodb鎖的信息。
- I/o相關(guān)：以io開頭，匯總了等待I/O、I/O使用量情況。
- 內(nèi)存使用情況：以memory開頭，從主機、線程、事件等角度展示內(nèi)存的使用情況
- 連接與會話信息：processlist和session相關(guān)視圖，總結(jié)了會話相關(guān)信息。
- 表相關(guān)：以schema_table開頭的視圖，展示了表的統(tǒng)計信息。
- 索引信息：統(tǒng)計了索引的使用情況，包含冗余索引和未使用的索引情況。
- 語句相關(guān)：以statement開頭，包含執(zhí)行全表掃描、使用臨時表、排序等的語句信息。
- 用戶相關(guān)：以user開頭的視圖，統(tǒng)計了用戶使用的文件I/O、執(zhí)行語句統(tǒng)計信息。
- 等待事件相關(guān)信息：以wait開頭，展示等待事件的延遲情況。
7.2 使用場景
索引情況
#1. 查詢?nèi)哂嗨饕?select * from sys.schema_redundant_indexes;
#2. 查詢未使用過的索引
select * from sys.schema_unused_indexes;
#3. 查詢索引的使用情況
select index_name,rows_selected,rows_inserted,rows_updated,rows_deleted
from sys.schema_index_statistics where table_schema='dbname';
表相關(guān)
# 1. 查詢表的訪問量
select table_schema,table_name,sum(io_read_requests+io_write_requests) as io from
sys.schema_table_statistics group by table_schema,table_name order by io desc;
# 2. 查詢占用bufferpool較多的表
select object_schema,object_name,allocated,data
from sys.innodb_buffer_stats_by_table order by allocated limit 10;
# 3. 查看表的全表掃描情況
select * from sys.statements_with_full_table_scans where db='dbname';
語句相關(guān)
#1. 監(jiān)控SQL執(zhí)行的頻率
select db,exec_count,query from sys.statement_analysis
order by exec_count desc;
#2. 監(jiān)控使用了排序的SQL
select db,exec_count,first_seen,last_seen,query
from sys.statements_with_sorting limit 1;
#3. 監(jiān)控使用了臨時表或者磁盤臨時表的SQL
select db,exec_count,tmp_tables,tmp_disk_tables,query
from sys.statement_analysis where tmp_tables>0 or tmp_disk_tables >0
order by (tmp_tables+tmp_disk_tables) desc;
IO相關(guān)文章來源：http://www.zghlxwxcb.cn/news/detail-431920.html
#1. 查看消耗磁盤IO的文件
select file,avg_read,avg_write,avg_read+avg_write as avg_io
from sys.io_global_by_file_by_bytes order by avg_read limit 10;
Innodb 相關(guān)文章來源地址http://www.zghlxwxcb.cn/news/detail-431920.html
#1. 行鎖阻塞情況
select * from sys.innodb_lock_waits;
到了這里，關(guān)于MySQL高級篇——性能分析工具的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
![[ARM 匯編]高級部分—性能優(yōu)化與調(diào)試—3.4.1 性能分析與優(yōu)化策略](https://imgs.yssmx.com/Uploads/2024/02/499151-1.jpg)
