導讀

有個表做了分割槽，每天一個分割槽。

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

待優化場景

有一個大表，每天產生的資料量約100萬，所以就採用表分割槽方案，每天一個分割槽。

下面是該表的DDL：

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

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

SQL優化之路

SQL優化思路

想要優化一個SQL，一般來說就是先看執行計劃，觀察是否儘可能用到索引，同時要關注預計掃描的行數，以及是否產生了臨時表（Using temporary）

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

SQL效能瓶頸定位

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

這個執行計劃看起來還好，有索引可用，也沒臨時表，也沒filesort。不過，我們也注意到，預計要掃描的行數還是挺多的 rows: 9384602，而且要掃描全部表分割槽，難怪效率不高，總是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及相應的執行計劃 沒有這些資訊的話，就別去麻煩別人了吧。

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