線上MySQL慢查詢現象案例--Impossible WHERE noticed after reading const tables

前言:2012年的筆記整理而得，發布個人博客，做備忘錄使用。
背景:線上慢查詢日志監控，得到如下的語句:
       發現：select doc_text from t_wiki_doc_text where doc_title = '謝澤源'; 這條語句昨天執行特別的慢

1.查看上述語句的執行計划:
  mysql> explain select doc_text from t_wiki_doc_text where doc_title = '謝澤源';

+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+

| 1 | SIMPLE | NULL | NULL | NULL | NULL | NULL | NULL | NULL |  Impossible WHERE noticed after reading const tables |

+----+-------------+-------+------+---------------+------+---------+------+------+-----------------------------------------------------+

1 row in set (0.01 sec)

發現了Impossible where noticed after reading const tables，這是一個有趣的現象？（經查找，這個會全表掃描）

解釋原因如下:

根據主鍵查詢或者唯一性索引查詢,如果這條數據沒有的話，它會全表掃描，然后得出一個結論，該數據不在表中。

對於高並發的庫來說，這條數據，會讓負載特別的高。

查看線上的表結構，也印證的上述說法:

| t_wiki_doc_text | CREATE TABLE `t_wiki_doc_text` (

`DOC_ID` bigint(12) NOT NULL COMMENT '詞條ID流水號',

`DOC_TITLE` varchar(255) NOT NULL COMMENT '條目原始標題',

`DOC_TEXT` mediumtext COMMENT '條目正文',

PRIMARY KEY (`DOC_ID`),

UNIQUE KEY `IDX_DOC_TITLE` (`DOC_TITLE`)（唯一索引）

) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

對此，我在自己的數據庫里面，做了一個測試。

----------------------------------------------------測試模擬-----------------------------------------------------------

1).建立一個有唯一索引的表。

CREATE TABLE `zsd01` (

`id` int(11) DEFAULT NULL,

`name` varchar(20) DEFAULT NULL,

UNIQUE KEY `idx_name` (`name`)

) ENGINE=InnoDB DEFAULT CHARSET=gbk

2).插入兩條數據

insert into zsd01 values(1,'a');

insert into zsd01 values(2,'b');

3).分析一個沒有數據記錄的執行計划。（例如select name from zsd01 where name ='c'; ）

mysql> explain select name from zsd01 where name ='c';

+----+-------------+-------+------+---------------+------+---------+------+-----

-+-----------------------------------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows

| Extra |

+----+-------------+-------+------+---------------+------+---------+------+-----

-+-----------------------------------------------------+

| 1 | SIMPLE | NULL | NULL | NULL | NULL | NULL | NULL | NULL

|  Impossible WHERE noticed after reading const tables |

+----+-------------+-------+------+---------------+------+---------+------+-----

-+-----------------------------------------------------+

發現跟上述情況一模一樣。

4.) 修改表結構為只有一般索引的情況。

CREATE TABLE `zsd01` (

`id` int(11) DEFAULT NULL,

`name` varchar(20) DEFAULT NULL,

KEY `idx_normal_name` (`name`)

) ENGINE=InnoDB DEFAULT CHARSET=gbk

5.) 查看執行計划。

mysql> explain select name from zsd01 where name ='c';

+----+-------------+-------+------+-----------------+-----------------+---------

+-------+------+--------------------------+

| id | select_type | table | type | possible_keys | key | key_len

| ref | rows | Extra |

+----+-------------+-------+------+-----------------+-----------------+---------

+-------+------+--------------------------+

| 1 | SIMPLE | zsd01 | ref | idx_normal_name | idx_normal_name | 43

| const | 1 | Using where; Using index |

+----+-------------+-------+------+-----------------+-----------------+---------

+-------+------+--------------------------+

1 row in set (0.00 sec)

發現，就正常走了一般索引，rows=1的執行開銷。

結論: 從上述的例子和現象可以看出，如果數據不用唯一的話，普通的索引比唯一索引更好用。