優化案例 | 分區表場景下的SQL優化

有個表做了分區，每天一個分區。 該表上有個查詢，經常隻查詢表中某一天資料，但每次都幾乎要掃描整個分區的所有資料，有什麼辦法進行優化嗎？

有一個大表，每天産生的資料量約100萬，是以就采用表分區方案，每天一個分區。

下面是該表的ddl：

該表上經常發生下面的慢查詢：

sql優化思路

想要優化一個sql，一般來說就是先看執行計劃，觀察是否盡可能用到索引，同時要關注預計掃描的行數，以及是否産生了臨時表（using temporary） 或者 是否需要進行排序（using filesort），想辦法消除這些情況。

更進一步的優化政策則可能需要調整程式代碼邏輯，甚至技術架構或者業務需求，這個動作比較大，一般非核心系統上的核心問題，不會這麼大動幹戈，絕大多數情況，還是需要靠dba盡可能發揮聰明才智來解決。

sql性能瓶頸定位

現在，我們來看下這個sql的執行計劃：

這個執行計劃看起來還好，有索引可用，也沒臨時表，也沒filesort。不過，我們也注意到，預計要掃描的行數還是挺多的 rows: 9384602，而且要掃描zheng整個分區的所有資料，難怪效率不高，總是slow query。

優化思考

我們注意到這個sql總是要查詢某一天的資料，這個表已經做了按天分區，那是不是可以忽略 where 子句中的 時間條件呢？

還有，既然去掉了 date 條件，反觀表ddl，剩下的條件貌似就沒有合适的索引了吧？

是以，我們嘗試建立一個索引：

[email protected][mydb]> alter table t1 add index iid (iid, icnt);

然後，把sql改造成下面這樣，再看下執行計劃：

這優化效果，杠杠滴。

事實上，如果不強制指定分區的話，也是可以達到優化效果的：

絕大多數的sql通過添加索引、适當調整sql代碼（例如調整驅動表順序）等簡單手法來完成。

多說幾句，遇到sql優化性能瓶頸問題想要在技術群裡請教時，麻煩先提供幾個必要的資訊：

表ddl 表正常統計資訊，可執行 show table status like 't1' 檢視 表索引分布資訊，可執行 show index from t1 檢視 有問題的sql及相應的執行計劃 沒有這些資訊的話，就别去麻煩别人了吧。 <b>本文來自雲栖社群合作夥伴“dbgeek”</b>