MySQL 5.6.30數據庫
因爲爬蟲抓取的數據不斷增多,這兩天在不斷對數據庫以及查詢語句進行優化,其中一個表結構以下:服務器
CREATE TABLE `newspaper_article` ( `id` varchar(50) NOT NULL COMMENT '編號', `title` varchar(190) NOT NULL COMMENT '標題', `author` varchar(255) DEFAULT NULL COMMENT '做者', `date` date NULL DEFAULT NULL COMMENT '發表時間', `content` longtext COMMENT '正文', `status` tinyint(4) DEFAULT '0', PRIMARY KEY (`id`), KEY `idx_status_date` (`status`,`date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='文章表';
根據業務須要,添加了 idx_status_date
索引,在執行下面這個 SQL 時特別耗時:數據結構
SELECT id, title, status, date FROM article WHERE status > -2 AND date = '2016-01-07';
根據觀察,天天新增的數據大概在2500條之內,本覺得這裏指定了具體某天的日期 '2016-01-07'
,實際須要掃描的數據量應該在2500條之內纔對,但實際並不是如此:
實際共掃描了185589條數據,遠遠高於預估的2500條,且實際執行時間都將近3秒鐘:性能
這是爲何呢?優化
將 idx_status_date (status, date)
改成 idx_status (status)
後,查看 MySQL 執行計劃:spa
能夠看到將多列索引改成單列索引後,執行計劃要掃描的數據總量沒有任何變化。結合多列索引遵循最左前綴原則,推測上面的查詢語句只使用了 idx_status_date
最左邊的 status
的索引。code
翻了下《高性能MySQL》找到了下面這段話,證明了個人想法:blog
若是查詢中有某個列的範圍查詢,則其右邊全部列都沒法使用索引優化查找。例若有查詢
WHERE last_name = 'Smith' AND first_name LIKE 'J%' AND dob = '1976-12-23'
,這個查詢只能使用索引的前兩列,由於這裏LIKE
是一個範圍條件(可是服務器能夠把其他列用於其餘目的)。若是範圍查詢列值的數量有限,那麼能夠經過使用多個等於條件來代替範圍條件。索引
所以,這裏解決思路有兩種:get
idx_status_date (status, date)
爲索引 idx_date_status (date, status)
,並新建一個 idx_status
索引,便可達到一樣的效果。優化後的執行計劃:
實際執行結果:
當人們談論索引的時候,若是沒有特別指明類型,那麼多半說的是 B-Tree
索引,它使用 B-Tree
數據結構來存儲數據。咱們使用術語「B-Tree」,是由於 MySQL 在 CREATE TABLE
和其餘語句中也使用該關鍵字。不過,底層的存儲引擎也可能使用不一樣的存儲結構。InnoDB使用的是B+Tree。
假若有以下數據表:
CREATE TABLE People ( last_name varchar(50) not null, first_name varchar(50) not null, dob date not null, gender enum('m', 'f') not null, key(last_name, first_name, dob) );
WHERE last_name = 'Smith' AND first_name LIKE 'J%' AND dob = '1976-12-23'
,這個查詢只能使用索引的前兩列,由於這裏 LIKE
是一個範圍條件(可是服務器能夠把其他列用於其餘目的)。若是範圍查詢列值的數量有限,那麼能夠經過使用多個等於條件來代替範圍條件。