Show Profile官方文檔地址：https://dev.mysql.com/doc/refman/5.7/en/show-profile.html

當我們在優化sql的時候可以使用explain來查看執行計劃，可當根據執行計劃優化完畢之后我們的sql的運行時間還是比較長，這時我們可以使用show profile

更細粒度的分析，show-profile，可以提高用來分析當前會話中語句執行的資源消耗情況,可以用于sql調優的測量.

1. 基本語法：

• 查看是否開啟：show variables like "%pro%";
• 開啟：set profiling = 1
• 查看SQL執行時間：show profiles;
• 查看記錄中第一條SQL詳細時間：show profile for query 1;

關于show Profile的基本用法請看上篇文章：通過Query Profiler查看MySQL語句運行時間

2. 通過type指定顯示其他信息

我們看一下官方提供的profile語法：

SHOW PROFILE [type [, type] ... ][FOR QUERY n][LIMIT row_count [OFFSET offset]]type: {ALL 顯示所有信息| BLOCK IO 顯示塊輸入和輸出操作的數量| CONTEXT SWITCHES 顯示自愿上下文切換和非自愿上下文切換的數量| CPU 顯示用戶和系統的CPU使用時間| IPC 顯示已發送和已接收消息（messages）的數量| MEMORY -- 尚未生效| PAGE FAULTS 顯示主要和次要頁面錯誤的數量| SOURCE 顯示源代碼中函數名稱以及該函數所在文件的名稱和行號| SWAPS 顯示SWAP數量 }

3. show profile返回的行和列

如下圖所示，是執行一個show profile all for query 3;命令顯示的結果集。我們根據行和列分別來分析一個每個字段的含義。

行字段的含義：

+---------------------+--------------+------+-----+----------+-------+ | Field | Type | Null | Key | Default | Extra | +---------------------+--------------+------+-----+----------+-------+ | QUERY_ID | int(20) | NO | | 0 | | # 語句ID | STATE | varchar(30) | NO | | | | # 狀態 | DURATION | decimal(9,6) | NO | | 0.000000 | | # 持續時間，單位s | CPU_USER | decimal(9,6) | YES | | NULL | | # 用戶態CPU時間，單位s | CPU_SYSTEM | decimal(9,6) | YES | | NULL | | # 系統態CPU時間，單位s | CONTEXT_VOLUNTARY | int(20) | YES | | NULL | | # 自愿上下文切換次數 | CONTEXT_INVOLUNTARY | int(20) | YES | | NULL | | # 非自愿上下文切換次數 | BLOCK_OPS_IN | int(20) | YES | | NULL | | # 塊輸入次數 | BLOCK_OPS_OUT | int(20) | YES | | NULL | | # 塊輸出次數 | MESSAGES_SENT | int(20) | YES | | NULL | | # 發送的消息數量 | MESSAGES_RECEIVED | int(20) | YES | | NULL | | # 接收的消息數量 | PAGE_FAULTS_MAJOR | int(20) | YES | | NULL | | # 主要頁面錯誤數量 | PAGE_FAULTS_MINOR | int(20) | YES | | NULL | | # 次要頁面錯誤數量 | SWAPS | int(20) | YES | | NULL | | # 交換次數 | SOURCE_FUNCTION | varchar(30) | YES | | NULL | | # 源代碼函數 | SOURCE_FILE | varchar(20) | YES | | NULL | | # 源代碼文件 | SOURCE_LINE | int(20) | YES | | NULL | | # 源代碼行數 +---------------------+--------------+------+-----+----------+-------+

列字段的含義：

* Sending data (最重要的一個過程★★★★★)線程正在讀取和處理一條SELECT語句的行，并且將數據發送至客戶端。由于在此期間會執行大量 的磁盤訪問（讀操作），這個狀態在一個指定查詢的生命周期中經常是耗時最長的。這個字段才是SQL真正運行采集+相應數據的時間，而非executing；--以下按照首字母順序依次排序* After create這個狀態當線程創建一個表（包括內部臨時表）時，在這個建表功能結束時出現。即使某些錯誤導致建表失敗，也會使用這個狀態。* Analyzing當計算MyISAM表索引分布時。（比如進行ANALYZE TABLE時）* checking permissions這個線程檢查服務器是否有具有執行該語句的所需權限。* Checking table線程正在執行表檢查操作。* cleaning up線程處理一個命令，并正準備釋放內存和重置某些狀態變量。* closing tables線程正在將變更的表中的數據刷新到磁盤上并正在關閉使用過的表。這應該是一個快速的操作。如果不是這樣的話則應該檢查硬盤空間是否已滿或者硬盤IO是否達到瓶頸。 * converting HEAP to MyISAM線程將一個內部臨時表轉換為磁盤上的MyISAM表。* copy to tmp table 線程正在處理一個ALTER TABLE語句。這個狀態發生在新的表結構已經創建之后，但是在數據被復制進入之前。* Copying to group table如果一個語句有不同的ORDER BY和GROUP BY條件，數據會被復制到一個臨時表中并且按組排序。* Copying to tmp table線程將數據寫入內存中的臨時表。 正在創建臨時表以存放部分查詢結果* Copying to tmp table on disk線程正在將數據寫入磁盤中的臨時表。臨時表的結果集過大。所以線程將臨時表由基于內存模式改為基于磁盤模式，以節省內存。但是這個過程會異常的緩慢！！* Creating index線程正在對一個MyISAM表執行ALTER TABLE ... ENABLE KEYS語句。* Creating sort index線程正在使用內部臨時表處理一個SELECT 操作。* creating table線程正在創建一個表，包括創建臨時表。* Creating tmp table線程正在創建一個臨時表在內存或者磁盤上。如果這個表創建在內存上但是之后被轉換到磁盤上，這個狀態在運行Copying to tmp table on disk 的時候保持。* deleting from main table線程正在執行多表刪除的第一部分，只從第一個表中刪除。并且保存列和偏移量用來從其他（參考）表刪除。* deleting from reference tables線程正在執行多表刪除的第二部分，并從其他表中刪除匹配的行。* discard_or_import_tablespace線程正在執行ALTER TABLE ... DISCARD TABLESPACE 或 ALTER TABLE ... IMPORT TABLESPACE語句。* end這個狀態出現在結束時，但是在對ALTER TABLE, CREATE VIEW, DELETE, INSERT, SELECT, 或者 UPDATE 語句進行清理之前。* executing該線程已開始執行一條語句。* Execution of init_command線程正在執行處于init_command系統變量的值中的語句。* freeing items * 線程已經執行了命令。在這個狀態中涉及的查詢緩存可以得到一些釋放。這個狀態通常后面跟隨cleaning up狀態。* Flushing tables線程正在執行FLUSH TABLES 并且等待所有線程關閉他們的表。* FULLTEXT initialization服務器正在準備進行自然語言全文檢索。* init這個狀態出現在線程初始化ALTER TABLE, DELETE, INSERT, SELECT, 或 UPDATE語句之前。服務器在這種狀態下進行的操作，包括：刷新全日志、Innodb日志，和一些查詢緩存清理操作。* Killed程序對線程發送了KILL語句，并且它應該放棄下一次對KILL標記的檢查。這個標記在每一個MySQL的主要循環中被檢查，但在某些情況下，它可能需要令線程在很短的時間內死亡。如果這個線程被其他線程鎖住了，這個KILL操作會在其他線程釋放鎖的瞬時執行。* logging slow query這個線程正在將語句寫入慢查詢日志。* NULL沒有操作的狀態。* login線程連接的初始狀態。直到客戶端已經成功驗證。* manage keys服務器啟用或禁用表索引。* Opening tables, Opening table線程正試圖打開一張表* optimizing服務器執行查詢的初步優化。* preparing在查詢優化過程中出現這個狀態。* Purging old relay logs線程正在移除不必要的中繼日志文件。* query end這個狀態出現在處理一個查詢之后，但是在freeing items狀態之前。* Reading from net服務器正在從網絡閱讀數據包。* Removing duplicates查詢正在使用SELECT DISTINCT，這種情況下MySQL不能在早期階段優化掉一些distinct操作。因此，MySQL需要一個額外的階段，在將結果發送到客戶端之前刪除所有重復的行。* removing tmp table線程正在移除一個內置臨時表，在執行一條SELECT語句之后。 如果沒有臨時表產生，那么這個狀態不被使用。* rename * 線程正在重命名一張表。* rename result table線程正在處理ALTER TABLE語句，創建新的表，并且重命名它來代替原有的表。* Reopen tables線程獲得了表鎖，但是在取得表鎖之后才發現該表的底層結構已經發生了變化。線程釋放這個鎖，關閉表，并試圖重新打開該表。* Repair by sorting修復代碼正在使用一個分類來創建索引。* Repair done線程完成一個多線程的MyISAM表的修復。* Repair with keycache修復代碼正在通過索引緩存一個接一個地使用創建索引。這比通過分類修復要慢很多。* Rolling back線程正在回滾一個事務* Searching rows for update線程正在進行第一階段，在更新前尋找所有匹配的行。如果update正在更改用于查找相關行的索引，則必須這么做。* setup線程正開始進行一個ALTER TABLE操作。* Sorting for group線程正在執行一個由GROUP BY指定的排序。* Sorting for order線程正在執行一個由ORDER BY指定的排序。* Sorting index線程正在對索引頁進行排序，為了對MyISAM表進行操作時獲得更優的性能。* Sorting result對于一個SELECT語句，這與創建排序索引相似，但是是對非臨時表。* statistics服務器計算統計去規劃一個查詢。如果一個線程長時間處于這個狀態，這個服務器的磁盤可能在執行其他工作。* System lock這個線程正在請求或者等待一個內部的或外部的系統表鎖。如果這個狀態是由于外部鎖的請求產生的，并且你沒有使用多個正在訪問相同的表的mysql服務器* Waiting for table level lock系統鎖定后的下一個線程狀態。線程已獲得外部鎖并且將請求內部表鎖。* Updating線程尋找更新匹配的行并進行更新。* updating main table線程正在執行多表更新的第一部分，只從第一個表中更新。并且保存列和偏移量用來從其他（參考）表更新。* updating reference tables線程正在執行多表更新的第二部分，并從其他表中更新匹配的行。* User lock線程正在請求或等待一個GET_LOCK()調用所要求的咨詢鎖。對于SHOW PROFILE，這個狀態意味這線程正在請求鎖。（而非等待）* User sleep線程調用了一個SLEEP()。* Waiting for commit lock一個顯式或隱式語句在提交時等待釋放讀鎖* Waiting for global read lock等待全局讀鎖。* Waiting for release of readlock等待釋放讀鎖。* Waiting for tables, Waiting for table, Waiting for table flush線程獲得一個通知，底層表結構已經發生變化，它需要重新打開表來獲取新的結構。然而，重新打開表，它必須等到所有其他線程關閉這個有問題的表。這個通知產生通常因為另一個線程對問題表執行了FLUSH TABLES或者以下語句之一：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, or OPTIMIZE TABLE.* Waiting for lock_type lock等待各個種類的表鎖。* Waiting on cond一個普通的狀態，線程正在等待一個條件為真。沒有特定的狀態信息可用。* Writing to net服務器正在寫一個網絡數據包。

3. SQL執行過程中可能導致時間慢的原因

1. Sending data (最重要的一個過程★★★★★)線程正在讀取和處理一條SELECT語句的行，并且將數據發送至客戶端。由于在此期間會執行大量的磁盤訪問（讀操作），這個狀態在一個指定查詢的生命周期中經常是耗時最長的。對于一個普通查詢來說，這個參數過大可分為兩種情況1. 第一種是SQL本身，比如沒有建立正確的索引，索引失效等等情況，這種數據體現在CPU_user 和CPU_sysyem字段 時間過長；2. 第二種是相應數據量過大，導致CPU調度時上下文頻繁切換。這種數據體現在CONTEXT_INVOLUNTARY和CONTEXT_VOLUNTARY字段 時間過長;像：外網使用Navicat連接到遠程數據庫中。查詢一個普通的SQL，在本地MySQL執行速度很快，但是使用遠程服務器的MySQL就異常的緩慢。這時若查詢profile詳情，就會發現大量相應數據傳輸IO導致頻繁的上下文切換消耗了大量的時間。2. converting HEAP to MyISAM原譯指的是：線程將一個內部臨時表轉換為磁盤上的MyISAM表。我們實際操作中可能出現的問題就是查詢結果太大了導致內存不夠，往磁盤上搬。3.Creating tmp table創建了臨時表4.Coping to tmp table on disk把內存中臨時表復制到磁盤5.locked加鎖------------------------------------------------ 2，4 可以修改一下tmp_table_size和max_heap_table_size兩個參數來調整

show profile語句已經棄用，并將在以后版本中移除，建議使用 Performance Schema

Performance Schema文檔：https://dev.mysql.com/doc/refman/5.7/en/performance-schema-query-profiling.html

總結

以上是生活随笔為你收集整理的MySQL中show profile详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。