當你寫入乙個select查詢語句，mysql底層會有查詢優化器來對你的拆線呢語句給出mysq自己的理解。人的理解與機器的理解存在偏差，從而造成查詢效能變慢這一重大影響。為了讓人能夠迎合機器的理解去更好的書寫sql查詢語句，我們需要對已存在的sql語句進行分析，看存在哪些問題才使得機器難以快速執行。而分析的手段就是explain計畫分析。
使用explain關鍵字可以模擬優化器執行sql查詢語句，從而知道mysql是如何處理你的sql語句的。分析你的查詢語句或是表結構的效能瓶頸。
explain+sql語句查詢的型別，主要是用於區別普通查詢、聯合查詢、子查詢等的複雜查詢
table：顯示這一行的資料是關於哪些表的。
type
type顯示的是訪問型別，是較為重要的乙個指標，結果值從最好到最壞依次是：
system>const>eq_ref>ref>range>index>all一般來說，得保證查詢至少達到range級別，最好能達到ref。possible_keys：顯示可能應用在這張表中的索引，乙個或多個。查詢涉及到的字段上若存在索引，則該索引將被列出。但不一定被查詢實際使用。key：實際使用的索引。如果為null，則沒有使用索引。查詢中若使用了覆蓋索引，則該索引僅出現在key列表中，不會出現在possible_keys列表中。（覆蓋索引：查詢的字段與建立的復合索引的個數一一吻合）
key_len：表示索引中使用的位元組數，可通過該列計算查詢中使用的索引的長度。在不損失精確性的情況下，長度越短越好。key_len顯示的值為索引欄位的最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的。
ref：顯示索引的哪一列被使用了，如果可能的話，是乙個常數。哪些列或常量被用於查詢索引列上的值。查詢中與其它表關聯的字段，外來鍵關係建立索引。
rows：根據表統計資訊及索引選用情況，大致估算出找到所需的記錄所需要讀取的行數。
extra：包含不適合在其他列中顯示但十分重要的額外資訊。
覆蓋索引：
JVM優化分析
看過了jvm的記憶體模型，自己總結一下jvm的優化過程。1.首先要分析情況，關注三大塊的情況 cpu 記憶體和io 磁碟 網路 jstack檢視執行緒cpu的使用情況，記憶體使用jmap來檢視記憶體使用情況，iostat來檢視磁碟讀寫情況 iotop也可以，但需要安裝 然後使用jinfo來列印下虛擬...
sql優化分析
sql 語句前加explain 分析sql掃瞄行數 table 顯示該語句涉及的表 type 這列很重要，顯示了連線使用了哪種類別,有無使用索引，反映語句的質量。possible keys 列指出mysql能使用哪個索引在該表中找到行 key 顯示mysql實際使用的鍵 索引 如果沒有選擇索引，鍵是...
oracle 優化分析
記錄下來，做資料庫優化和索引分析的方案 案例 1 在分割槽表中，全域性索引可能會導致索引失效，這樣執行計畫中不走索引，改本地索引local 2 對錶進行分析，不用analyze，用了會對執行計畫產生影響，對錶和索引分析建議用dbms exec dbms stats.gather table stat...