1.使用explain，查看查詢計劃

2.使用show processlist查看查詢過程（處于哪個狀態(tài)），完整命令如下 mysql -uroot -p -e ‘show processlist G’ |grep state: |sort|uniq -c|sort -rn 此種方法和方法3類似，應(yīng)該說方法3更好用。

3.使用show profile。 默認是禁止的，需要使用set profiling = 1開啟。執(zhí)行一些查詢后，鍵入show profiles可以看到前面執(zhí)行語句的查詢時間以很高的精度顯示了出來。然后使用show profile for query n就可以看到對應(yīng)查詢語句的查詢執(zhí)行的每個步驟以及其花費的時間。

4.使用慢日志，并用第三方工具pt-query-digest生成分析報告。使用這種分析方法時，很有可能需要更改配置文件，可以設(shè)置成如下形式： log_slow_queries = /var/log/mysql/mysql-slow.log#日志的存放目錄 long_query_time = 0 //捕獲所有的查詢 log-queries-not-using-indexes//即使不使用索引也可以被記錄

在項目中發(fā)現(xiàn)程序執(zhí)行的時間幾乎全部消耗在了數(shù)據(jù)庫的操作上。用pt-query-digest對慢查詢?nèi)罩咀龀龇治鰣蟾?實際生產(chǎn)中無法方便的打開和關(guān)閉慢查詢?nèi)罩荆藭r可以通過監(jiān)聽TCP流量即使用tcpdump來模擬)，發(fā)現(xiàn)update和insert操作占到了所有時間的95%。

于是進一步分析執(zhí)行的語句。

這條update語句各部分耗時如下：

可以看出時間主要耗費在了query end狀態(tài)中。

google上得到答案，將mysql的配置文件my.conf里加上一句innodb_flush_log_at_trx_commit = 0。 經(jīng)過驗證，成功解決問題，速度提升非常明顯（上面的改動同時對insert操作也起了作用）。 同時留下疑問：query end是什么狀態(tài)，為什么會用這么久的時間，為什么加上innodb_flush_log_at_trx_commit = 0后性能提升會這么大？

query end是什么狀態(tài)？ mysql的官方文檔解釋是：This state occurs after processing a query but before the freeing items state.我的理解是語句執(zhí)行完畢了，但是還有一些后續(xù)工作沒做完時的狀態(tài)。

那么freeing items 又是什么狀態(tài)呢？ The thread has executed a command. Some freeing of items done during this state involves the query cache. This state is usually followed by cleaning up.就是釋放查詢緩存里面的空間（因為是update操作，所以相應(yīng)的緩存里的記錄就無效了，所以需要有這一步做處理）。

innodb_flush_log_at_trx_commit的默認值是1，此時的行為是： the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file。log buffer的作用:允許事務(wù)在執(zhí)行完成之后才將日志（事務(wù)需要維護一個日志）寫到磁盤上，時間主要應(yīng)該就是耗費在磁盤IO上？

而將innodb_flush_log_at_trx_commit的值改為0后，行為如下： If the value of innodb_flush_log_at_trx_commit is 0, the log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file, but nothing is done at a transaction commit。 可以看到，改成0后，本來應(yīng)該每次提交都進行的操作，變成了每秒鐘才進行一次，所以及大的節(jié)省了時間。

將innodb_flush_log_at_trx_commit的值設(shè)置為0有一個副作用：任何服務(wù)器端mysql程序的崩潰會導(dǎo)致最后一秒的事務(wù)丟失(還沒來得及到到日志文件中)。但是考慮到本應(yīng)用對事務(wù)不必有如此嚴格的要求，所以這是可以接受的。

來自：http://inetkiller.github.io/2014/05/20/mysql語句性能分析與優(yōu)化/