MySQL高階 之 索引面試題分析
索引優化簡單案例
單表
需求：查詢category_id為1 且 comments大於1 的情況下，views最多的id
1、無索引的情況下：
很顯然，type是ALL，即最壞的情況，Extra還出現了Using filesort也是最壞的情況，必須優化
2、優化一：where條件全部建索引
複合索引中的使用到的“comments > 1”是一個範圍檢索，帶來的好處是將type提升為range，只需檢索部分索引，但卻導致mysql無法利用索引再對後面的views部分進行檢索，即導致後面views索引的失效，“ORDER BY views DESC”不得不進行檔案排序
補充：
BTree索引的工作原理：先排序category_id，如果遇到相同的category_id則再排序comments，如果遇到相同的comments，則再排序views。
3、優化二：刪除失效的索引
兩表
需求：兩表關聯查詢
1、無索引的情況下
2、優化一：左表建索引
2、優化二：右表建索引
由上可見，左連線查詢，左表資料一定都有，不可避免的需要全表掃描，所以右表是我們優化的關鍵，需要建立合適的索引提高檢索效率。同理，右連線左表索引是關鍵。
三表
1、無索引的情況下
2、優化：右表建索引
總結：
1、儘可能減少join語句中的NestedLoop的迴圈總次數，永遠用小表（小的結果集）驅動大表（大的結果集）
2、優先優化NestedLoop的內層迴圈
3、保證join語句中被驅動的表上Join條件欄位已經別索引
索引面試題分析
資料準備：
問題：建立了複合索引idx_test03_c1234，根據以下sql分析索引使用情況？
1、sql欄位順序變化
mysql查詢優化器會自動對sql語句進行優化，最終都會優化成符合索引順序的sql也就是第一條sql的樣子。
2、範圍之後全失效 + sql欄位順序變化
第一條sql由於c3範圍查詢，導致後面的c4索引失效
第二條sql由於mysql查詢優化器的優化，c3被優化到c4前面，索引都沒有失效
３、order by 單列
4、order by 多列
c2已經按常量檢索了，值是固定的，再排序就沒有意義了，所以不會產生檔案排序。
5、group by
group by之前基本上都需要排序，如果沒有排序，排序時還會產生零時表。