此筆記為尚硅谷MySQL高級篇部分內(nèi)容

目錄

一、數(shù)據(jù)庫服務(wù)器的優(yōu)化步驟

二、查看系統(tǒng)性能參數(shù)

三、統(tǒng)計SQL的查詢成本：last_query_cost

四、定位執(zhí)行慢的 SQL：慢查詢?nèi)罩?/p>

1、開啟慢查詢?nèi)罩緟?shù)

2、查看慢查詢數(shù)目

3、慢查詢?nèi)罩痉治龉ぞ撸簃ysqldumpslow

4、關(guān)閉慢查詢?nèi)罩?/p>

5、刪除慢查詢?nèi)罩?/p>

五、查看 SQL 執(zhí)行成本：SHOW PROFILE

六、分析查詢語句：EXPLAIN ?

1、概述

2、基本語法?

3、EXPLAIN各列作用

1. table

2. id?

3.select_type?

4.partitions (可略)

5. type ☆

6.possible_keys和key

7.key_len ☆

8.ref

9.rows ☆

10.filtered

11.Extra ☆

12.小結(jié)

七、EXPLAIN的進一步使用

1、EXPLAIN四種輸出格式

1. 傳統(tǒng)格式

2. JSON格式

3.TREE格式

4.可視化輸出

2、SHOW WARNINGS的使用

八、分析優(yōu)化器執(zhí)行計劃：trace

九、MySQL監(jiān)控分析視圖-sys schema

1、Sys schema視圖摘要

2、Sys schema視圖使用場景?

一、數(shù)據(jù)庫服務(wù)器的優(yōu)化步驟

當(dāng)我們遇到數(shù)據(jù)庫調(diào)優(yōu)問題的時候，該如何思考呢？這里把思考的流程整理成下面這張圖。
整個流程劃分成了 觀察（Show status） 和 行動（Action） 兩個部分。字母 S 的部分代表觀察（會使用相應(yīng)的分析工具），字母 A 代表的部分是行動（對應(yīng)分析可以采取的行動）。

小結(jié)：

二、查看系統(tǒng)性能參數(shù)

在MySQL中，可以使用 SHOW STATUS 語句查詢一些MySQL數(shù)據(jù)庫服務(wù)器的 性能參數(shù) 、 執(zhí)行頻率 。

SHOW STATUS語句語法如下：

SHOW [GLOBAL|SESSION] STATUS LIKE '參數(shù)';

一些常用的性能參數(shù)如下：

• Connections：連接MySQL服務(wù)器的次數(shù)。

• Uptime：MySQL服務(wù)器的上線時間。

• Slow_queries：慢查詢的次數(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ù)。

三、統(tǒng)計SQL的查詢成本：last_query_cost

一條SQL查詢語句在執(zhí)行前需要確定查詢執(zhí)行計劃，如果存在多種執(zhí)行計劃的話，MySQL會計算每個執(zhí)行計劃所需要的成本，從中選擇成本最小的一個作為最終執(zhí)行的執(zhí)行計劃。

如果我們想要查看某條SQL語句的查詢成本，可以在執(zhí)行完這條SQL語句之后，通過查看當(dāng)前會話中的 last_query_cost變量值來得到當(dāng)前查詢的成本。它通常也是我們評價一個查詢的執(zhí)行效率的一個常用指標(biāo)。這個查詢成本對應(yīng)的是SQL語句所需要讀取的頁的數(shù)量。

使用場景：它對于比較開銷是非常有用的，特別是我們有好幾種查詢方式可選的時候。

四、定位執(zhí)行慢的 SQL：慢查詢?nèi)罩?/h2>

---

MySQL的慢查詢?nèi)罩荆脕碛涗浽贛ySQL中響應(yīng)時間超過閥值的語句，具體指運行時間超過long_query_time值的SQL，則會被記錄到慢查詢?nèi)罩局小ong_query_time的默認值為10，意思是運行10秒以上(不含10秒)的語句，認為是超出了我們的最大忍耐時間值。

它的主要作用是，幫助我們發(fā)現(xiàn)那些執(zhí)行時間特別長的SQL查詢，并且有針對性地進行優(yōu)化，從而提高系統(tǒng)的整體效率。當(dāng)我們的數(shù)據(jù)庫服務(wù)器發(fā)生阻塞、運行變慢的時候，檢查一下慢查詢?nèi)罩?，找到那些慢查詢，對解決問題很有幫助。比如一條sq|執(zhí)行超過5秒鐘，我們就算慢SQL，希望能收集超過5秒的sql，結(jié)合explain進行全面分析。

默認情況下，MySQL數(shù)據(jù)庫沒有開啟慢查詢?nèi)罩?/code>，需要我們手動來設(shè)置這個參數(shù)。如果不是調(diào)優(yōu)需要的話，一般不建議啟動該參數(shù)，因為開啟慢查詢?nèi)罩緯蚨嗷蛏賻硪欢ǖ男阅苡绊?/p>

慢查詢?nèi)罩局С謱⑷罩居涗泴懭胛募?/p>

1、開啟慢查詢?nèi)罩緟?shù)

1.開啟slow_query_log

mysql > set global slow_query_log='ON';

2. 修改long_query_time閾值

接下來我們來看下慢查詢的時間閾值設(shè)置，使用如下命令：

mysql > show variables like '%long_query_time%';

這里如果我們想把時間縮短，比如設(shè)置為 1 秒，可以這樣設(shè)置：

#測試發(fā)現(xiàn)：設(shè)置global的方式對當(dāng)前session的long_query_time失效。對新連接的客戶端有效。所以可以一并
執(zhí)行下述語句
mysql > set global long_query_time = 1;
mysql> show global variables like '%long_query_time%';
mysql> set long_query_time=1;
mysql> show variables like '%long_query_time%';

2、查看慢查詢數(shù)目

查詢當(dāng)前系統(tǒng)中有多少條慢查詢記錄

SHOW GLOBAL STATUS LIKE '%Slow_queries%';

3、慢查詢?nèi)罩痉治龉ぞ撸簃ysqldumpslow

在生產(chǎn)環(huán)境中，如果要手工分析日志，查找、分析SQL，顯然是個體力活，MySQL提供了日志分析工具mysqldumpslow 。
查看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: 后邊搭配一個正則匹配模式，大小寫不敏感的

工作常用參考：?

#得到返回記錄集最多的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

4、關(guān)閉慢查詢?nèi)罩?/h4>

除了調(diào)優(yōu)需要開，正常還是不要開了

MySQL服務(wù)器停止慢查詢?nèi)罩竟δ苡袃煞N方法：

5、刪除慢查詢?nèi)罩?/h4>

提示：慢查詢?nèi)罩径际鞘褂胢ysqladmin flush-logs命令來刪除重建的。使用時-定要注意，一旦執(zhí)行了這個命令，慢 查詢?nèi)罩径贾淮嬖谛碌娜罩疚募?，如果需要舊的查詢?nèi)罩荆捅仨毷孪葌浞荨?/p>

五、查看 SQL 執(zhí)行成本：SHOW PROFILE

---

Show Profile是MySQL提供的可以用來分析當(dāng)前會話中SQL都做了什么、執(zhí)行的資源消耗情況的工具，可用于sql調(diào)優(yōu)的測量。默認情況下處于關(guān)閉狀態(tài)，并保存最近15次的運行結(jié)果。 ?

show variables like 'profiling';

--通過設(shè)置 profiling='ON’ 來開啟 show profile：
mysql > set profiling = 'ON';

--然后執(zhí)行相關(guān)的查詢語句。接著看下當(dāng)前會話都有哪些 profiles，使用下面這條命令：
mysql > show profiles;

--你能看到當(dāng)前會話一共有 2 個查詢。如果我們想要查看最近一次查詢的開銷，可以使用：
mysql > show profile;

--我們也可以查看指定的Query lD的開銷，比如`show profile for query 2`查詢結(jié)果是一樣的。在SHOWPROFILE中我們可以查看不同部分的開銷，比如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ù)開銷信息。

六、分析查詢語句：EXPLAIN ?

---

1、概述

官網(wǎng)介紹
https://dev.mysql.com/doc/refman/5.7/en/explain-output.html
https://dev.mysql.com/doc/refman/8.0/en/explain-output.html

定位了查詢慢的SQL之后，我們就可以使用EXPLAIN或DESCRIBE工具做針對性的分析查詢語句。DESCRIBE語句的使用方法與EXPLAIN語句是一樣的，并且分析結(jié)果也是一樣的。

MySQL中有專門負責(zé)優(yōu)化SELECT語句的優(yōu)化器模塊，主要功能: 通過計算分析系統(tǒng)中收集到的統(tǒng)計信息，為客戶端請求的Query提供它認為最優(yōu)的執(zhí)行計劃（他認為最優(yōu)的數(shù)據(jù)檢索方式，但不見得是DBA認為是最優(yōu)的，這部分最耗費時間)。

這個執(zhí)行計劃展示了接下來具體執(zhí)行查詢的方式，比如多表連接的順序是什么，對于每個表采用什么訪問方法來具體執(zhí)行查詢等等。MySQL為我們提供了EXPLAIN語句來幫助我們查看某個查詢語句的具體執(zhí)行計劃，大家看懂EXPLAIN語句的各個輸出項，可以有針對性的提升我們查詢語句的性能。

能做什么?

• 表的讀取順序

• 數(shù)據(jù)讀取操作的操作類型。

• 哪些索引可以使用

• 哪些索引被實際使用

• 表之間的引用

• 每張表有多少行被優(yōu)化器查詢

2、基本語法?

EXPLAIN 或 DESCRIBE語句的語法形式如下：

EXPLAIN SELECT select_options
--或者
DESCRIBE SELECT select_options

EXPLAIN 語句輸出的各個列的作用如下：

列名	描述
id	在一個大的查詢語句中每個SELECT關(guān)鍵字都對應(yīng)一個 唯一的id
select_type	SELECT關(guān)鍵字對應(yīng)的那個查詢的類型
table	表名
partitions	匹配的分區(qū)信息
type	針對單表的訪問方法（重要）
possible_keys	可能用到的索引
key	實際上使用的索引
key_len	實際使用到的索引長度
ref	當(dāng)使用索引列等值查詢時，與索引列進行等值匹配的對象信息
rows	預(yù)估的需要讀取的記錄條數(shù)
filtered	某個表經(jīng)過搜索條件過濾后剩余記錄條數(shù)的百分比
Extra	一些額外的信息

3、EXPLAIN各列作用

具體使用例子可以查看上傳的代碼包

1. table

不論我們的查詢語句有多復(fù)雜，里邊兒 包含了多少個表 ，到最后也是需要對每個表進行 單表訪問 的，所以MySQL規(guī)定EXPLAIN語句輸出的每條記錄都對應(yīng)著某個單表的訪問方法，該條記錄的table列代表著該表的表名（有時不是真實的表名字，可能是簡稱）。

2. id?

正常來說一個select 一個id ，也有例外的可能，查詢優(yōu)化器做了優(yōu)化

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 = 'a';

mysql> EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key1 FROM s2) OR key3 = 'a';

查詢優(yōu)化器優(yōu)化

 ######查詢優(yōu)化器可能對涉及子查詢的查詢語句進行重寫,轉(zhuǎn)變?yōu)槎啾聿樵兊牟僮?#######
 EXPLAIN SELECT * FROM s1 WHERE key1 IN (SELECT key2 FROM s2 WHERE common_field = 'a');

Union去重?

原本想的1個select 一個 id , 預(yù)計兩個。

--Union去重
EXPLAIN SELECT * FROM s1 UNION SELECT * FROM s2;
--union all 不去重  所以不需要放在臨時表里面
EXPLAIN SELECT * FROM s1 UNION ALL SELECT * FROM s2;

小結(jié):

• id如果相同，可以認為是一組，從上往下順序執(zhí)行

• 在所有組中，id值越大，優(yōu)先級越高，越先執(zhí)行

• 關(guān)注點：id號每個號碼，表示一趟獨立的查詢, 一個sql的查詢趟數(shù)越少越好

3.select_type?

一條大的查詢語句里邊可以包含若干個SELECT關(guān)鍵字，每個SELECT關(guān)鍵字代表著一個小的查詢語句，而每個SELECT關(guān)鍵字的FROM子句中都可以包含若干張表(這些表用來做連接查詢)，每一張表都對應(yīng)著執(zhí)行計劃輸出中的一條記錄，對于在同一個SELECT關(guān)鍵字中的表來說，它們的id值是相同的。

MySQL為每一個SELECT關(guān)鍵字代表的小查詢都定義了一個稱之為select_type的屬性，意思是我們只要知道了某個小查詢的select_type屬性，就知道了這個小查詢在整個大查詢中扮演了一個什么角色，我們看一下 select_type都能取哪些值，請看官方文檔:

名稱	描述
SIMPLE	Simple SELECT (not using UNION or subqueries)
PRIMARY	Outermost SELECT
UNION	Second or later SELECT statement in a UNION
UNION RESULT	Result of a UNION
SUBQUERY	First SELECT in subquery
DEPENDENT SUBQUERY	First SELECT in subquery, dependent on outer query
DEPENDENT UNION	Second or later SELECT statement in a UNION, dependent on outer query
DERIVED	Derived table
MATERIALIZED	Materialized subquery
UNCACHEABLE SUBQUERY	A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query
UNCACHEABLE UNION	The second or later select in a UNION that belongs to an uncacheable subquery (see UNCACHEABLE SUBQUERY)

4.partitions (可略)

代表分區(qū)表中的命中情況，非分區(qū)表，該項為NULL。一般情況下我們的查詢語句的執(zhí)行計劃的partitions列的值都是NULL。

5. type ☆

執(zhí)行計劃的一條記錄就代表著MySQL對某個表的執(zhí)行查詢時的訪問方法，又稱"訪問類型”，其中的type列就表明了這個訪問方法是啥，是較為重要的一個指標(biāo)。比如，看到type列的值是ref，表明MySQL即將使用ref訪問方法來執(zhí)行對s1表的查詢。

完整的訪問方法如下： system ， const ， eq_ref ， ref ， fulltext ， ref_or_null ，index_merge ， unique_subquery ， index_subquery ， range ， index ， ALL 。

--`system`  當(dāng)表中`只有一條記錄`并且該表使用的存儲引擎的統(tǒng)計數(shù)據(jù)是精確的，比如MyISAM、Memory，那么對該表的訪問方法就是`system`。

--const #當(dāng)我們根據(jù)主鍵或者唯一二級索引列與常數(shù)進行等值匹配時，對單表的訪問方法就是`const`

--eq_ref #在連接查詢時，如果被驅(qū)動表是通過主鍵或者唯一二級索引列等值匹配的方式進行訪問的（如果該主鍵或者唯一二級索引是聯(lián)合索引的話，所有的索引列都必須進行等值比較），則對該被驅(qū)動表的訪問方法就是`eq_ref`

--ref #當(dāng)通過普通的二級索引列與常量進行等值匹配時來查詢某個表，那么對該表的訪問方法就可能是`ref`

--fulltext 全文索引

--ref_or_null #當(dāng)對普通二級索引進行等值匹配查詢，該索引列的值也可以是`NULL`值時，那么對該表的訪問方法就可能是`ref_or_null`

--index_merge  #單表訪問方法時在某些場景下可以使用`Intersection`、`Union`、`Sort-Union`這三種索引合并的方式來執(zhí)行查詢

--unique_subquery #`unique_subquery`是針對在一些包含`IN`子查詢的查詢語句中，如果查詢優(yōu)化器決定將`IN`子查詢，轉(zhuǎn)換為`EXISTS`子查詢，而且子查詢可以使用到主鍵進行等值匹配的話，那么該子查詢執(zhí)行計劃的`type`，列的值就是`unique_subquery`

--`index_subquery`

--range  #如果使用索引獲取某些`范圍區(qū)間`的記錄，那么就可能使用到`range`訪問方法

--index #當(dāng)我們可以使用索引覆蓋，但需要掃描全部的索引記錄時，該表的訪問方法就是`index`

--ALL #一般來說，這些訪問方法中除了`All`這個訪問方法外，其余的訪問方法都能用到索引，除了`index_merge`訪問方法外，其余的訪問方法都最多只能用到一個索引。

小結(jié):

結(jié)果值從最好到最壞依次是：

system > const > eq_ref > ref >

fulltext > ref_or_null > index_merge >unique_subquery > index_subquery > range >?

index > ALL?

SQL 性能優(yōu)化的目標(biāo)：至少要達到 range 級別，要求是 ref 級別，最好是 consts級別。（阿里巴巴 開發(fā)手冊要求）

6.possible_keys和key

在EXPLAIN語句輸出的執(zhí)行計劃中， possible_keys列表示在某個查詢語句中，對某個表執(zhí)行單表查詢時可能用到的索引有哪些。一般查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢使用。key列表示實際用到的索引有哪些，如果為NULL，則沒有使用索引。

7.key_len ☆

• key_len：實際使用到的索引長度(即：字節(jié)數(shù))

• key_len越小 索引效果越好 這是前面學(xué)到的只是，短一點效率更高

• 但是在聯(lián)合索引里面，命中一次key_len加一次長度。越長代表精度越高，效果越好

8.ref

當(dāng)使用索引列等值查詢時，與索引列進行等值匹配的對象信息。比如只是一個常數(shù)或者是某個列

9.rows ☆

rows：預(yù)估的需要讀取的記錄條數(shù)，`值越小越好`，通常與filtered 一起使用

rows 值越小，代表，數(shù)據(jù)越有可能在一個頁里面，這樣io就會更小。

10.filtered

越大越好? filtered 的值指返回結(jié)果的行占需要讀到的行(rows 列的值)的百分比。

如果使用的是索引執(zhí)行的單表掃描，那么計算時需要估計出滿足除使用到對應(yīng)索引的搜索條件外的其他搜索條件的記錄有多少條。

對于單表查詢來說，這個filtered列的值沒什么意義，我們更關(guān)注在連接查詢中驅(qū)動表對應(yīng)的執(zhí)行計劃記錄的filtered值，它決定了被驅(qū)動表要執(zhí)行的次數(shù)(即：rows * filtered)

11.Extra ☆

顧名思義，Extra列是用來說明一些額外信息的，包含不適合在其他列中顯示但十分重要的額外信息。我們可以通過這些額外信息來更準(zhǔn)確的理解MySQL到底將如何執(zhí)行給定的查詢語句。

12.小結(jié)

• EXPLAIN不考慮各種Cache
• EXPLAIN不能顯示MySQL在執(zhí)行查詢時所作的優(yōu)化工作
• EXPLAIN不會告訴你關(guān)于觸發(fā)器、存儲過程的信息或用戶自定義函數(shù)對查詢的影響情況
• 部分統(tǒng)計信息是估算的，并非精確值?

七、EXPLAIN的進一步使用

---

1、EXPLAIN四種輸出格式

這里談?wù)凟XPLAIN的輸出格式。EXPLAIN可以輸出四種格式： 傳統(tǒng)格式 ， JSON格式 ， TREE格式 以及 可視化輸出 。用戶可以根據(jù)需要選擇適用于自己的格式。

1. 傳統(tǒng)格式

2. JSON格式

3.TREE格式

TREE格式是8.0.16版本之后引入的新格式，主要根據(jù)查詢的 各個部分之間的關(guān)系 和 各部分的執(zhí)行順序 來描述如何查詢

4.可視化輸出

可視化輸出，可以通過MySQL Workbench可視化查看MySQL的執(zhí)行計劃。通過點擊Workbench的放大鏡圖標(biāo)，即可生成可視化的查詢計劃。

上圖按從左到右的連接順序顯示表。紅色框表示 全表掃描 ，而綠色框表示使用 索引查找 。對于每個表，顯示使用的索引。還要注意的是，每個表格的框上方是每個表訪問所發(fā)現(xiàn)的行數(shù)的估計值以及訪問該表的成本。

2、SHOW WARNINGS的使用

八、分析優(yōu)化器執(zhí)行計劃：trace

---

?開啟后，可分析如下語句：

• SELECT

• INSERT

• REPLACE

• UPDATE

• DELETE

• EXPLAIN

• SET

• DECLARE

• CASE

• IF

• RETURN

• CALL

測試：執(zhí)行如下SQL語句

select * from student where id < 10;

最后， 查詢 information_schema.optimizer_trace 就可以知道MySQL是如何執(zhí)行SQL的 :

select * from information_schema.optimizer_trace\G

mysql> select * from information_schema.optimizer_trace\G
*************************** 1. row ***************************
# //第1部分：查詢語句
QUERY: select * from student where id < 10
//第2部分：QUERY字段對應(yīng)語句的跟蹤信息
TRACE: {
  "steps": [
    {
      "join_preparation": { /*預(yù)備工作*/
        "select#": 1,
        "steps": [
          {
            "expanded_query": "/* select#1 */ select `student`.`id` AS `id`,`student`.`stuno` AS `stuno`,`student`.`name` AS `name`,`student`.`age` AS `age`,`student`.`classId` AS `classId` from `student` where (`student`.`id` < 10)"
          }
        ] /* steps */
      } /* join_preparation */
    },
    {
      "join_optimization": {/*進行優(yōu)化*/
        "select#": 1,
        "steps": [
          {
            "condition_processing": {/*條件處理*/
              "condition": "WHERE",
              "original_condition": "(`student`.`id` < 10)",
              "steps": [
                {
                  "transformation": "equality_propagation",
                  "resulting_condition": "(`student`.`id` < 10)"
                },
                {
                  "transformation": "constant_propagation",
                  "resulting_condition": "(`student`.`id` < 10)"
                },
                {
                  "transformation": "trivial_condition_removal",
                  "resulting_condition": "(`student`.`id` < 10)"
                }
              ] /* steps */
            } /* condition_processing */
          },
          {
            "substitute_generated_columns": {/*替換生成的列*/
            } /* substitute_generated_columns */
          },
          {
            "table_dependencies": [   /* 表的依賴關(guān)系*/
              {
                "table": "`student`",
                "row_may_be_null": false,
                "map_bit": 0,
                "depends_on_map_bits": [
                ] /* depends_on_map_bits */
              }
            ] /* table_dependencies */
          },
          {
            "ref_optimizer_key_uses": [ /* 使用鍵*/
            ] /* ref_optimizer_key_uses */
          },
          {
            "rows_estimation": [ /*行判斷*/
              {
                "table": "`student`",
                "range_analysis": {
                  "table_scan": {
                    "rows": 3945207,
                    "cost": 404306
                  } /* table_scan */,/*表掃描*/
                  "potential_range_indexes": [
                    {
                      "index": "PRIMARY",
                      "usable": true,
                      "key_parts": [
                        "id"
                      ] /* key_parts */
                    }
                  ] /* potential_range_indexes */,
                  "setup_range_conditions": [ 
                  ] /* 設(shè)置條件范圍 */,
                  "group_index_range": {
                    "chosen": false,
                    "cause": "not_group_by_or_distinct"
                  } /* group_index_range */,
                  "skip_scan_range": {
                    "potential_skip_scan_indexes": [
                      {
                        "index": "PRIMARY",
                        "usable": false,
                        "cause": "query_references_nonkey_column"
                      }
                    ] /* potential_skip_scan_indexes */
                  } /* skip_scan_range */,
                  "analyzing_range_alternatives": {/*分析范圍選項*/
                    "range_scan_alternatives": [
                      {
                        "index": "PRIMARY",
                        "ranges": [
                          "id < 10"
                        ] /* ranges */,
                        "index_dives_for_eq_ranges": true,
                        "rowid_ordered": true,
                        "using_mrr": false,
                        "index_only": false,
                        "in_memory": 0.159895,
                        "rows": 9,
                        "cost": 1.79883,
                        "chosen": true
                      }
                    ] /* range_scan_alternatives */,
                    "analyzing_roworder_intersect": {
                      "usable": false,
                      "cause": "too_few_roworder_scans"
                    } /* analyzing_roworder_intersect */
                  } /* analyzing_range_alternatives */,
                  "chosen_range_access_summary": {/*選擇范圍訪問摘要*/
                    "range_access_plan": {
                      "type": "range_scan",
                      "index": "PRIMARY",
                      "rows": 9,
                      "ranges": [
                        "id < 10"
                      ] /* ranges */
                    } /* range_access_plan */,
                    "rows_for_plan": 9,
                    "cost_for_plan": 1.79883,
                    "chosen": true
                  } /* chosen_range_access_summary */
                } /* range_analysis */
              }
            ] /* rows_estimation */
          },
          {
            "considered_execution_plans": [/*考慮執(zhí)行計劃*/
              {
                "plan_prefix": [
                ] /* plan_prefix */,
                "table": "`student`",
                "best_access_path": {/*最佳訪問路徑*/
                  "considered_access_paths": [
                    {
                      "rows_to_scan": 9,
                      "access_type": "range",
                      "range_details": {
                        "used_index": "PRIMARY"
                      } /* range_details */,
                      "resulting_rows": 9,
                      "cost": 2.69883,
                      "chosen": true
                    }
                  ] /* considered_access_paths */
                } /* best_access_path */,
                "condition_filtering_pct": 100, /*行過濾百分比*/
                "rows_for_plan": 9,
                "cost_for_plan": 2.69883,
                "chosen": true
              }
            ] /* considered_execution_plans */
          },
          {
            "attaching_conditions_to_tables": { /*將條件附加到表上*/
              "original_condition": "(`student`.`id` < 10)",
              "attached_conditions_computation": [
              ] /* attached_conditions_computation */,
              "attached_conditions_summary": [ /*附加條件概要*/
                {
                  "table": "`student`",
                  "attached": "(`student`.`id` < 10)"
                }
              ] /* attached_conditions_summary */
            } /* attaching_conditions_to_tables */
          },
          {
            "finalizing_table_conditions": [
              {
                "table": "`student`",
                "original_table_condition": "(`student`.`id` < 10)",
                "final_table_condition   ": "(`student`.`id` < 10)"
              }
            ] /* finalizing_table_conditions */
          },
          {
            "refine_plan": [ /*精簡計劃*/
              {
                "table": "`student`"
              }
            ] /* refine_plan */
          }
        ] /* steps */
      } /* join_optimization */
    },
    {
      "join_execution": {  /*執(zhí)行*/
        "select#": 1,
        "steps": [
        ] /* steps */
      } /* join_execution */
    }
  ] /* steps */
}
/
/*第3部分：跟蹤信息過長時，被截斷的跟蹤信息的字節(jié)數(shù)。*/
MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0 /*丟失的超出最大容量的字節(jié)*/
/*第4部分：執(zhí)行跟蹤語句的用戶是否有查看對象的權(quán)限。當(dāng)不具有權(quán)限時，該列信息為1且TRACE字段為空，一般在
調(diào)用帶有SQL SECURITY DEFINER的視圖或者是存儲過程的情況下，會出現(xiàn)此問題。*/
INSUFFICIENT_PRIVILEGES: 0 /*缺失權(quán)限*/
1 row in set (0.01 sec)

九、MySQL監(jiān)控分析視圖-sys schema

---

1、Sys schema視圖摘要

1. 主機相關(guān)：以host_summary開頭，主要匯總了IO延遲的信息。

2. Innodb相關(guān)：以innodb開頭，匯總了innodb buffer信息和事務(wù)等待innodb鎖的信息。

3. I/o相關(guān)：以io開頭，匯總了等待I/O、I/O使用量情況。

4.內(nèi)存使用情況：以memory開頭，從主機、線程、事件等角度展示內(nèi)存的使用情況

5.連接與會話信息：processlist和session相關(guān)視圖，總結(jié)了會話相關(guān)信息。

6. 表相關(guān)：以schema_table開頭的視圖，展示了表的統(tǒng)計信息。

7. 索引信息：統(tǒng)計了索引的使用情況，包含冗余索引和未使用的索引情況。

8.語句相關(guān)：以statement開頭，包含執(zhí)行全表掃描、使用臨時表、排序等的語句信息。

9. 用戶相關(guān)：以user開頭的視圖，統(tǒng)計了用戶使用的文件I/O、執(zhí)行語句統(tǒng)計信息。

10.等待事件相關(guān)信息：以wait開頭，展示等待事件的延遲情況。

2、Sys schema視圖使用場景?

注意：通過sys庫去查詢時，MySQL會消耗大量資源去收集相關(guān)信息，嚴(yán)重的可能會導(dǎo)致業(yè)務(wù)請求被阻塞，從而引起故障。建議生產(chǎn)上不要頻繁的去查詢sys或performance_schema、information_schema來完成監(jiān)控、巡檢等工作。

高級篇筆記PDF自取

鏈接：https://pan.baidu.com/s/1pVqrTwIZFoED77i-EFmw6g?pwd=3333?
提取碼：3333文章來源地址http://www.zghlxwxcb.cn/news/detail-470545.html

到了這里，關(guān)于【MySQL高級篇筆記-性能分析工具的使用 (中) 】的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！