剖析單條查詢（）
從結果可以看到該查詢使用了三個臨時表其中兩個是磁盤臨時表並且有很多的沒有用到索引的讀操作（Handler_read_rnd_next）假設我們不知道這個視圖的具體定義僅從結果來推測這個查詢有可能是做了多表關聯（join）查詢並且沒有合適的索引可能是其中一個子查詢創建了臨時表然後和其他表做聯合查詢而用於保存子查詢結果的臨時表沒有索引如此大致可以解釋這樣的結果
使用這個技術的時候要注意SHOW STATUS 本身也會創建一個臨時表而且也會通過句柄操作訪問此臨時表這會影響到SHOW STATUS 結果中對應的數字而且不同的版本可能行為也不盡相同比較前面通過SHOW PROFILES 獲得的查詢的執行計劃的結果來看至少臨時表的計數器多加了
你可能會注意到通過EXPLAIN 查看查詢的執行計劃也可以獲得大部分相同的信息但EXPLAIN 是通過估計得到的結果而通過計數器則是實際的測量結果例如EXPLAIN 無法告訴你臨時表是否是磁盤表這和內存臨時表的性能差別是很大的附錄D 包含更多關於EXPLAIN 的內容
使用慢查詢日志
那麼針對上面這樣的查詢語句Percona Server 對慢查詢日志做了哪些改進？下面是使用SHOW PROFILE一節演示過的相同的查詢執行後抓取到的結果
# Time: ::
# User@Host: root[root] @ localhost []
# Thread_id: Schema: sakila Last_errno: Killed:
# Query_time: Lock_time: Rows_sent: Rows_examined:
Rows_affected: Rows_read:
# Bytes_sent: Tmp_tables: Tmp_disk_tables: Tmp_table_sizes:
# InnoDB_trx_id: E
# QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: Yes Tmp_table_on_disk: Yes
# Filesort: Yes Filesort_on_disk: No Merge_passes:
# InnoDB_IO_r_ops: InnoDB_IO_r_bytes: InnoDB_IO_r_wait:
# InnoDB_rec_lock_wait: InnoDB_queue_wait:
# InnoDB_pages_distinct:
# PROFILE_VALUES … Copying to tmp table: … [omitted]
SET timestamp=;
SELECT * FROM sakilanicer_but_slower_film_list;
從這裡看到查詢確實一共創建了三個臨時表其中兩個是磁盤臨時表而SHOW PROFILE看起來則隱藏了信息（可能是由於服務器執行查詢的方式有不一樣的地方造成的）這裡為了方便閱讀對結果做了簡化但最後對該查詢執行SHOW PROFILE 的數據也會寫入到日志中所以在Percona Server 中甚至可以記錄SHOW PROFILE 的細節信息
[] []
From:http://tw.wingwit.com/Article/program/MySQL/201311/29706.html
