线上MySQL慢查询现象案例

  • 时间:
  • 浏览:7
  • 来源:大发彩神8下载最新版—大发快三官网大发彩神

发现了Impossible where noticed after reading const tables,这是一1个有趣的现象?(经查找,你这个会全表扫描)

前言:2012年的笔记整理而得,发布被委托人博客,做备忘录使用。

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

| t_wiki_doc_text | CREATE TABLE `t_wiki_doc_text` (

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

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

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

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

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

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

对此,我在被委托人的数据库后面 ,做了一1个测试。 ----------------------------------------------------测试模拟-----------------------------------------------------------

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

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

3).分析一1个没人数据记录的执行计划。(你这个select name from zsd01 where name ='c'; )

) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

1.查看上述励志的话 的执行计划:

Impossible WHERE noticed after reading const tables |

`DOC_TITLE` varchar(255) NOT NULL COMMENT '条目原始标题',

`name` varchar(20) DEFAULT NULL,

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

`name` varchar(20) DEFAULT NULL,

`id` int(11) DEFAULT NULL,

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

) ENGINE=InnoDB DEFAULT CHARSET=gbk

| const | 1 | Using where; Using index |

解释愿因如下:

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

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

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

KEY `idx_normal_name` (`name`)

CREATE TABLE `zsd01` (

1 row in set (0.00 sec)

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

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

对于高并发的库来说,这条数据,会让负载一阵一阵的高。

| Extra |

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

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

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

UNIQUE KEY `idx_name` (`name`)

`DOC_ID` bigint(12) NOT NULL COMMENT '词条ID流水号',

背景:线上慢查询日志监控,得到如下的励志的话 :

| ref | rows | Extra |

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

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

CREATE TABLE `zsd01` (

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

发现跟上述情况一模一样。

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

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

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

根据主键查询将会唯一性索引查询,将会这条数据没人励志的话 ,它会全表扫描,过后得出一1个结论,该数据没哟表中。

) ENGINE=InnoDB DEFAULT CHARSET=gbk

5.) 查看执行计划。

`id` int(11) DEFAULT NULL,

查看线上的表形状,也印证的上述说法:

4.) 修改表形状为能不都还都可否 了一般索引的情况。

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

发现,就正常走了一般索引,rows=1的执行开销。

PRIMARY KEY (`DOC_ID`),

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

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

结论:从上述的例子和现象能不都还都可否 看出,将会数据不用唯一励志的话 ,普通的索引比唯一索引更好用。