利用MySQL的PROFILE功能，我們可以很方便的查看一個SQL具體的執行代價是怎樣的，尤其是可以分析它的最大瓶頸在哪里。目前PROFILE功能可提供除了內存以外的其他資源消耗統計，例如CPU、I/O、CONTEXT、SWAP等。 PROFILE功能只能在SESSION級別使用，還做不到像SQL Server那樣可以全局開啟，收集一段時間后再關閉，這點有待改進。關于PROFILE的具體用法大家可以查看手冊?[13.7.5.31 SHOW PROFILE Syntax](http://dev.mysql.com/doc/refman/5.6/en/show-profile.html)，這里不細說。 大部分情況下，PROFILE的結果我們主要關注兩列：Status、Duration，前者表示的是PROFILE里的狀態，它和PROCESSLIST的狀態基本是一致的，后者是該狀態的耗時。因此，我們最主要的是關注處于哪個狀態耗時最久，這些狀態中，哪些可以進一步優化。 和我們之前的一個分享?[[MySQL FAQ]系列 — processlist中哪些狀態要引起關注](http://imysql.com/2015/06/10/mysql-faq-processlist-thread-states.shtml "編輯“[MySQL FAQ]系列 — processlist中哪些狀態要引起關注”")?類似，PROFILE中，下面幾種狀態是要尤其關注的，而且大多數通過創建合適的索引就可以完成優化。 | Status | 建議 | |------|--------| | System lock | 確認是由于哪個鎖引起的，通常是因為MySQL或InnoDB內核級的鎖引起的建議：如果耗時較大再關注即可，一般情況下都還好 | | Sending data | 從server端發送數據到客戶端，也有可能是接收存儲引擎層返回的數據，再發送給客戶端，數據量很大時尤其經常能看見（備注：Sending Data不是網絡發送，是從硬盤讀取，發送到網絡是Writing to net 建議：通過索引或加上LIMIT，減少需要掃描并且發送給客戶端的數據量） | | Sorting result | 正在對結果進行排序，類似Creating sort index，不過是正常表，而不是在內存表中進行排序（建議：創建適當的索引） | | Table lock | 表級鎖，沒什么好說的，要么是因為MyISAM引擎表級鎖，要么是其他情況顯式鎖表 | | create sort index | 當前的SELECT中需要用到臨時表在進行ORDER BY排序（建議：創建適當的索引） | | checking query cache for querychecking privileges on cachedsending cached result to clien storing result in query cache | 和query cache相關的狀態，已經多次強烈建議關閉 | 更多狀態請移步之前的分享文章?[[MySQL FAQ]系列 — processlist中哪些狀態要引起關注](http://imysql.com/2015/06/10/mysql-faq-processlist-thread-states.shtml "編輯“[MySQL FAQ]系列 — processlist中哪些狀態要引起關注”")?以及官方文檔?[8.14.2 General Thread States](http://dev.mysql.com/doc/refman/5.6/en/general-thread-states.html)，如果有未涉及想了解的狀態，也請在評論區給我留言，謝謝。