線上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的執行開銷。

結論: 從上述的例子和現象能夠看出，若是數據不用惟一的話，普通的索引比惟一索引更好用。