三、總結
查詢在長沙的女性vip顧客
sql語句：select * from customers1s where city=「長沙」 and gender=0;
開啟trace檢視優化器
set optimizer_trace=
"enabled=on"
;--開啟trace檢視優化器的結果
set end_markers_in_json=on;
--增加注釋
show warnings\g
;//分析上面執行語句，底層的的重寫
select * from information_schema.optimizer_trace \g
;--查詢列印執行計畫
select id,`name`,city,monthsalary,gender from customers1s where city=「長沙」 and gender=0 and monthsalary=99;#setup_range_conditions：如果有可下推的條件，則帶條件考慮範圍查詢
「setup_range_conditions」: [
] / setup_range_conditions /,
#group_index_range：當使用了group by或distinct時，是否有合適的索引可用。當未使用group by或distinct時，會顯示chosen=false, cause=not_group_by_or_distinct；如使用了group by或 distinct，但是多表查詢時，會顯示chosen=false，cause =not_single_table。其他情況下會嘗試 分析可用的索引（potential_group_range_indexes）並計算對應的掃瞄行數及其所需代價
「group_index_range」: / group_index_range /,
#analyzing_range_alternatives：分析各個索引的使用成本
「analyzing_range_alternatives」:
] / range_scan_alternatives /,
#analyzing_roworder_intersect：分析是否使用了索引合併（index merge），如果未使用， 會在cause中展示原因；如果使用了索引合併，會在該部分展示索引合併的代價。
「analyzing_roworder_intersect」: / analyzing_roworder_intersect /
} / analyzing_range_alternatives /,
#chosen_range_access_summary：在前乙個步驟中分析了各類索引使用的方法及代價，得出了 一定的中間結果之後，在summary階段彙總前一階段的中間結果確認最後的方案
「chosen_range_access_summary」: / range_access_plan /,
「rows_for_plan」: 471868,#該執行計畫的掃瞄行數
「cost_for_plan」: 56304,#該執行計畫的執行代價
「chosen」: true #是否選擇該執行計畫
} / chosen_range_access_summary /
} / range_analysis /
}] / rows_estimation /},,
/ range_details /,
「chosen」: false,
「cause」: 「heuristic_index_cheaper」
}] / considered_access_paths /
} / best_access_path /,
「condition_filtering_pct」: 100, #類似於explain的filtered列，是乙個估算值
「rows_for_plan」: 471868,#執行計畫最終的掃瞄行數，由considered_access_paths.rows x condition_filtering_pct計算獲得。
「cost_for_plan」: 56304,#執行計畫的代價，由considered_access_paths.cost相加獲得
「chosen」: true #是否選擇了該執行計畫
}] / considered_execution_plans /
},] / attached_conditions_summary /
} / attaching_conditions_to_tables /
},] / refine_plan /
}] / steps /
} / join_optimization /
}, / join_execution /
}] / steps */
}finalizing_table_conditions 最終的、經過優化後的表條件。
] /* finalizing_table_conditions */
}1.確定查詢的表（多對多那就是多表）
2.查詢字段資訊，字段型別資訊，索引資訊等
3.重寫sql語句或者是where條件。
4.判斷索引使用
在explain條件下
alter table customers1s add index idx_city_gender(city,gender)
;
select
*from customers1s where city="長沙" and gender=0;
s:9s多
explain select
*from customers1s where city="長沙" and gender=0;
原因分析 使用了索引idx_city_gender,idx_city_gender索引樹上儲存的是主鍵、city、gender,但查詢的是所有字段，又根據索引對應的主鍵，查詢了滿足條件的資料 ，即產生了回表。
回表查詢的本質：索引當中並不存在sql語句需要查詢的資料
連線層 -》 sql層 （優化器：得到最優的執行計畫 idx_city_gender）=》查詢資料的時候發現索引
並不滿足需要查詢資料 =》 通過查詢的資料的主鍵索引去磁碟重查詢資料 =》返回資料
select id,city,gender from customers1s where city="長沙" and gender=0;
s:0.21s
explain select id,city,gender from customers1s where city="長沙" and gender=0;
連線層 =》 sql層 （優化器：得到最優的執行計畫 idx_city_gender）=》查詢資料 =》 返回資料
連線層 =》 sql層 （優化器：得到最優的執行計畫 idx_city_gender）=》查詢資料的時候發現索引
並不滿足需要查詢資料 =》 通過查詢的資料的主鍵索引去磁碟重查詢資料 =》還需要通過where來進行資料過濾 =》 返回資料
即：索引過濾 =》回表 =》非索引過濾
1. 先看查詢使用的索引
2. 確定索引資料
3. 在預判sql語句掃瞄的資料與索引資料做對比
4. 在確定這個sql執行是不是最好
MySQL優化器與執行器
經過了分析器，mysql 就知道你要做什麼了。在開始執行之前，還要先經過優化器的處理。優化器是在表裡面有多個索引的時候，決定使用哪個索引 或者在乙個語句有多表關聯 join 的時候，決定各個表的連線 順序。比如你執行下面這樣的語句，這個語句 是執行兩個表的 join mysql select fro...
HAL MODULE 執行過程分析
hal module 執行過程分析 1.其初始化過程如下 system.loadlibrary led runtime jni onload registermethods env registernatives clazz,gmethods,sizeof gmethods sizeof gmeth...
sql執行過程分析
我們總是寫sql語句，資料庫把結果返回給我們，那中間過程又是什麼？如果了解oracle是怎麼執行sql語句的中間過程，對我們優化sql有很大的幫助 首先了解一下執行sql，需要消耗什麼資源，cpu，記憶體，io，我們要了解什麼情況下會消耗cpu，什麼情況下消耗記憶體，什麼情況下消耗io，只有了解了這...