背景
线上慢查询日志监控，得到以下的语句:
发现：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 |
对此，我在自己的数据库里面，做了一个测试。
2.测试摹拟
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的履行开消。
结论:从上述的例子和现象可以看出，如果数据不用唯一的话，普通的索引比唯一索引更好用。
到此这篇关于MySQL慢查询现象解决案例的文章就介绍到这了,更多相关MySQL慢查询内容请搜索之前的文章或继续浏览下面的相关文章希望大家以后多多支持！
文章来源：丸子建站
文章标题：MySQL慢查询现象解决案例
https://www.wanzijz.com/view/61354.html
