MySQL 調優之性能監控

MySQL基本架構：

想要了解SQL的性能，我們需要先了解下MySQL是如何玩起來的：

• 連接器：負責跟客戶端建立連接，獲取權限，維持和管理連接，包括用戶名密碼驗證，權限的查詢與分配，自動斷開連接等，可分爲長連接和短連接。
• 查詢緩存：當執行查詢語句的時候，先去查詢緩存中的數據，如果能找到結果則直接返回，如果沒有，再去數據庫中進行查詢。如果數據更新比較頻繁，只要表更新，緩存就會被清空，此時不建議使用緩存，命中率會比較低。（MySQL5.8已經廢棄這個功能）
• 分析器：1. 語法分析，根據語法規則判斷當前的sql是否滿足mysql的語法，如果不滿足則報錯
  2.詞法分析，如select id from student，需要將字符串"student"識別成表student，字符串"id"識別成列id
  最終生成ASTree，簡稱抽象語法樹
• 優化器：在具體執行SQL語句之前，語句要經過優化處理：如，當表中有多個索引時，決定用哪個索引；當表需要進行join時，需要決定表的連接順序等。不同的執行順序對性能影響很大。主要有兩種優化方式：RBO（基於規則優化），CBO（基於成本優化），主要是使用CBO
• 執行器：執行實際的SQL語句，主要是跟存儲引擎進行交互。
• 存儲引擎：定義數據不同的存放位置以及文件不同的存儲格式：
  InnoDB：存儲在磁盤
  MyIsam：存儲在磁盤
  memory：存儲在內存
  other：其他存儲引擎

內容\ 格式	MyIsam	InnoDB
存儲格式	每個MyISAM在磁盤上存儲成三個文件： .frm文件存儲表的定義 .MYD 文件存儲具體數據 .MYI存儲索引數據	InnoDB表空間數據文件（.idb）和它的日誌文件（redo）
事務	不支持	支持
場景	大量select	大量增刪改
鎖	表鎖	行鎖、表鎖
外鍵	不支持	支持
索引類型	非聚簇索引	聚簇索引

以MySQL5.8，mac OS爲例，新建study數據庫，新建兩張表：student、greade，默認存儲路徑：/usr/local/mysql/data/：

show profile

MySQL官方規定後續版本可能不在支持這個功能，目前最新的5.8還是支持這個功能的
我們先來查詢下student表裏的數據：

顯示耗時用了0秒，我們實際知道這個肯定是時間精度的問題，肯定是有耗時的，那具體怎麼看這條SQL耗時多少呢？
我們首先需要開啓show profile：

set profiling=1;

然後我們就可以輸入show profile命令查看：

我們就可以看到MySQL在執行這條命令的每一個過程中，花費了多少時間。
PS：show profile僅顯示最後執行的那條SQL執行信息。

如果我們想看所有已經執行了的SQL信息怎麼辦呢？這時候我們就可以使用show profiles命令了：

那show profile命令怎麼使用呢：

SHOW PROFILE [type [, type] ... ]
    [FOR QUERY n]
    [LIMIT row_count [OFFSET offset]]

type: {
  |  ALL 				（所有信息信息）
  | BLOCK IO			（顯示塊IO操作的次數）
  | CONTEXT SWITCHES	（顯示上下文切換的次數，包括主動和被動）
  | CPU					（顯示CPU使用情況）
  | IPC					（顯示發送和接收的消息數量）
  | MEMORY		
  | PAGE FAULTS			（顯示錯誤數量）
  | SOURCE				（顯示源碼中函數名稱和位置）	
  | SWAPS				（顯示swap次數）
}

官網文檔地址：

https://dev.mysql.com/doc/refman/8.0/en/show-profile.html

用上圖的例子，假設我們現在想查看第2條SQL語句執行時CPU的運行情況：

show profile CPU for query 2;

performance schema

performance schema 用於監控MySQL server在一個較底層的運行過程中的資源消耗、資源等待等情況，MySQL默認開啓該功能。
下面我們來查看下數據庫：

我們可以看到，默認已經有了一個叫performance_schema的數據庫，我們進入該數據庫中看下里面的表信息：

我們可以看到裏面定義了大一堆的表，有account賬戶相關，有data數據相關，有event事件相關，還有replication複製相關，等等。
performance_schema 數據庫中的表使用performance_schema存儲引擎。該數據庫主要關注數據庫運行過程中的性能相關的數據，與information_schema不同，information_schema主要關注server運行過程中的元數據信息。
我們通過查看相應的表就能查詢是SQL性能信息。

總結部分可能使用到比較多的SQL：

--1、哪類的SQL執行最多？
SELECT DIGEST_TEXT,COUNT_STAR,FIRST_SEEN,LAST_SEEN FROM events_statements_summary_by_digest ORDER BY COUNT_STAR DESC
--2、哪類SQL的平均響應時間最多？
SELECT DIGEST_TEXT,AVG_TIMER_WAIT FROM events_statements_summary_by_digest ORDER BY COUNT_STAR DESC
--3、哪類SQL排序記錄數最多？
SELECT DIGEST_TEXT,SUM_SORT_ROWS FROM events_statements_summary_by_digest ORDER BY COUNT_STAR DESC
--4、哪類SQL掃描記錄數最多？
SELECT DIGEST_TEXT,SUM_ROWS_EXAMINED FROM events_statements_summary_by_digest ORDER BY COUNT_STAR DESC
--5、哪類SQL使用臨時表最多？
SELECT DIGEST_TEXT,SUM_CREATED_TMP_TABLES,SUM_CREATED_TMP_DISK_TABLES FROM events_statements_summary_by_digest ORDER BY COUNT_STAR DESC
--6、哪類SQL返回結果集最多？
SELECT DIGEST_TEXT,SUM_ROWS_SENT FROM events_statements_summary_by_digest ORDER BY COUNT_STAR DESC
--7、哪個表物理IO最多？
SELECT file_name,event_name,SUM_NUMBER_OF_BYTES_READ,SUM_NUMBER_OF_BYTES_WRITE FROM file_summary_by_instance ORDER BY SUM_NUMBER_OF_BYTES_READ + SUM_NUMBER_OF_BYTES_WRITE DESC
--8、哪個表邏輯IO最多？
SELECT object_name,COUNT_READ,COUNT_WRITE,COUNT_FETCH,SUM_TIMER_WAIT FROM table_io_waits_summary_by_table ORDER BY sum_timer_wait DESC
--9、哪個索引訪問最多？
SELECT OBJECT_NAME,INDEX_NAME,COUNT_FETCH,COUNT_INSERT,COUNT_UPDATE,COUNT_DELETE FROM table_io_waits_summary_by_index_usage ORDER BY SUM_TIMER_WAIT DESC
--10、哪個索引從來沒有用過？
SELECT OBJECT_SCHEMA,OBJECT_NAME,INDEX_NAME FROM table_io_waits_summary_by_index_usage WHERE INDEX_NAME IS NOT NULL AND COUNT_STAR = 0 AND OBJECT_SCHEMA <> 'mysql' ORDER BY OBJECT_SCHEMA,OBJECT_NAME;
--11、哪個等待事件消耗時間最多？
SELECT EVENT_NAME,COUNT_STAR,SUM_TIMER_WAIT,AVG_TIMER_WAIT FROM events_waits_summary_global_by_event_name WHERE event_name != 'idle' ORDER BY SUM_TIMER_WAIT DESC
--12-1、剖析某條SQL的執行情況，包括statement信息，stege信息，wait信息
SELECT EVENT_ID,sql_text FROM events_statements_history WHERE sql_text LIKE '%count(*)%';
--12-2、查看每個階段的時間消耗
SELECT event_id,EVENT_NAME,SOURCE,TIMER_END - TIMER_START FROM events_stages_history_long WHERE NESTING_EVENT_ID = 1553;
--12-3、查看每個階段的鎖等待情況
SELECT event_id,event_name,source,timer_wait,object_name,index_name,operation,nesting_event_id FROM events_waits_history_longWHERE nesting_event_id = 1553;

performance schema官網地址：

https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html