《優化案例 | 分區表場景下的SQL優化》要點：
本文介紹了優化案例 | 分區表場景下的SQL優化，希望對您有用。如果有疑問，可以聯系我們。

導讀

有個表做了分區,每天一個分區.

該表上有個查詢,經常只查詢表中某一天數據,但每次都幾乎要掃描整個分區的所有數據,有什么辦法進行優化嗎?

待優化場景

有一個大表,每天產生的數據量約100萬,所以就采用表分區方案,每天一個分區.

下面是該表的DDL：

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

SELECT … FROM `t1` WHERE `date` = ‘2017-04-01’ AND `icnt` > 300 AND `id` = ‘801301’;

SQL優化之路

SQL優化思路

想要優化一個SQL,一般來說就是先看執行計劃,觀察是否盡可能用到索引,同時要關注預計掃描的行數,以及是否產生了臨時表(Using temporary)?或者?是否需要進行排序(Using filesort),想辦法消除這些情況.

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

SQL性能瓶頸定位

現在,我們來看下這個SQL的執行計劃：

這個執行計劃看起來還好,有索引可用,也沒臨時表,也沒filesort.不過,我們也注意到,預計要掃描的行數還是挺多的?rows: 9384602,而且要掃描全部表分區,難怪效率不高,總是SLOW QUERY.

優化思考

我們注意到這個SQL總是要查詢某一天的數據,這個表已經做了按天分區,那是不是可以忽略?WHERE 子句中的 時間條件呢?

還有,既然去掉了 date 條件,反觀表DDL,剩下的條件貌似就沒有合適的索引了吧?

所以,我們嘗試新建一個索引：

yejr@imysql.com[myDB]> ALTER TABLE t1 ADD INDEX iid (iid, icnt);

然后,把SQL改造成下面這樣,再看下執行計劃：

這優化效果,杠杠滴.

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

后記

絕大多數的SQL通過添加索引、適當調整SQL代碼(例如調整驅動表順序)等簡單手法來完成.

多說幾句,遇到SQL優化性能瓶頸問題想要在技術群里請教時,麻煩先提供幾個必要的信息：

• 表DDL
• 表常規統計信息,可執行 SHOW TABLE STATUS LIKE ‘t1’ 查看
• 表索引分布信息,可執行 SHOW INDEX FROM t1 查看
• 有問題的SQL及相應的執行計劃 沒有這些信息的話,就別去麻煩別人了吧.

原文來自微信公眾號：老葉茶館

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4269.html