導讀

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

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

待優化場景

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

下面是該表的DDL：

CREATE TABLE `t1` (
 `id` bigint(20) NOT NULL AUTO_INCREMENT,`date` date NOT NULL,`kid` int(11) DEFAULT '0',`uid` int(11) NOT NULL,`iid` int(11) DEFAULT '0',`icnt` int(8) DEFAULT '0',`tst` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,`countp` smallint(11) DEFAULT '1',`isr` int(2) NOT NULL DEFAULT '0',`clv` int(5) NOT NULL DEFAULT '1'，
 PRIMARY KEY (`id`,`date`),UNIQUE KEY `date` (`date`,`uid`,`iid`),KEY `date_2` (`date`,`kid`)
) ENGINE=InnoDB AUTO_INCREMENT=3180686682 DEFAULT CHARSET=utf8mb4
/*!50500 PARTITION BY RANGE COLUMNS(`date`)
(PARTITION p20161201 VALUES LESS THAN ('2016-12-02') ENGINE = InnoDB,PARTITION p20161202 VALUES LESS THAN ('2016-12-03') ENGINE = InnoDB,PARTITION p20161203 VALUES LESS THAN ('2016-12-04') ENGINE = InnoDB,

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

SELECT ... FROM `t1` WHERE `date` = '2017-04-01' AND `icnt` > 300 AND `id` = '801301';

SQL優化之路

SQL優化思路

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

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

SQL效能瓶頸定位

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

[email protected][myDB]> EXPLAIN PARTITIONS SELECT ... FROM `t1` WHERE 
 `date` = '2017-03-02' AND `icnt` > 100 AND `iid` = '502302'\G
*************************** 1. row ***************************
   id: 1
 select_type: SIMPLE
  table: t1
 partitions: p20170302
   type: range
possible_keys: date,date_2
   key: date
  key_len: 3
   ref: const
   rows: 9384602
  Extra: Using where

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

優化思考

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

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

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

[email protected][myDB]> ALTER TABLE t1 ADD INDEX iid (iid,icnt);

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

[email protected][myDB]> EXPLAIN PARTITIONS SELECT ... FROM `t1` partition(p2017030) WHERE 
 `icnt` > 100 AND `iid` = '502302'\G
*************************** 1. row ***************************
   id: 1
 select_type: SIMPLE
  table: t1
 partitions: p20170302
   type: ref
possible_keys: date,date_2,iid
   key: iid
  key_len: 10
   ref: const
   rows: 7800
  Extra: Using where
這優化效果，槓槓滴。

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

[email protected][myDB]> EXPLAIN PARTITIONS SELECT ... FROM `t1` WHERE 
 `date` = '2017-03-02' AND `icnt` > 100 AND `iid` = '502302'\G
*************************** 1. row ***************************
   id: 1
 select_type: SIMPLE
  table: t1
 partitions: p20170302
   type: ref
possible_keys: date,iid
   key: iid
  key_len: 10
   ref: NULL
   rows: 7800
  Extra: Using where

後記

絕大多數的SQL通過新增索引、適當調整SQL程式碼（例如調整驅動表順序）等簡單手法來完成。

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

• 表DDL
• 表常規統計資訊，可執行 SHOW TABLE STATUS LIKE ‘t1' 檢視
• 表索引分佈資訊，可執行 SHOW INDEX FROM t1 檢視
• 有問題的SQL及相應的執行計劃 沒有這些資訊的話，就別去麻煩別人了吧。

以上就是分割槽表場景下的 SQL 優化的詳細內容，更多關於sql分割槽表優化的資料請關注我們其它相關文章！