explain 查看SQL执行计划

最新推荐文章于 2024-04-08 10:07:01 发布
最新推荐文章于 2024-04-08 10:07:01 发布
阅读量2.4k 收藏 12
点赞数 4
分类专栏： MySQL 文章标签： mysql调优
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/demored/article/details/123146976
版权

目录

一、环境准备

二、explain 输出解释

id

select_type

table

type

possible_keys

key

key_len

ref

rows

Extra

MySQL EXPLAIN命令是查询性能优化不可缺少的一部分,常常用到explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描。

一、环境准备

创建2张表user_info 和order_info

#创建user_info 表
CREATE TABLE `user_info` (
    `id`   BIGINT(20)  NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(50) NOT NULL DEFAULT '',
    `age`  INT(11)   DEFAULT NULL,
    PRIMARY KEY (`id`),
    KEY `name_index` (`name`)
)ENGINE = InnoDB DEFAULT CHARSET = utf8;


INSERT INTO user_info (name, age) VALUES ('xys', 20);
INSERT INTO user_info (name, age) VALUES ('a', 21);
INSERT INTO user_info (name, age) VALUES ('b', 23);
INSERT INTO user_info (name, age) VALUES ('c', 50);
INSERT INTO user_info (name, age) VALUES ('d', 15);
INSERT INTO user_info (name, age) VALUES ('e', 20);
INSERT INTO user_info (name, age) VALUES ('f', 21);
INSERT INTO user_info (name, age) VALUES ('g', 23);
INSERT INTO user_info (name, age) VALUES ('h', 50);
INSERT INTO user_info (name, age) VALUES ('i', 15);

#创建order_info表
CREATE TABLE `order_info` (
    `id`           BIGINT(20)  NOT NULL AUTO_INCREMENT,
    `user_id`      BIGINT(20)           DEFAULT NULL,
    `product_name` VARCHAR(50) NOT NULL DEFAULT '',
    `productor`    VARCHAR(30)          DEFAULT NULL,
    PRIMARY KEY (`id`),
    KEY `user_product_detail_index` (`user_id`, `product_name`, `productor`)
)ENGINE = InnoDB DEFAULT CHARSET = utf8;

INSERT INTO order_info (user_id, product_name, productor) VALUES (1, 'p1', 'WHH');
INSERT INTO order_info (user_id, product_name, productor) VALUES (1, 'p2', 'WL');
INSERT INTO order_info (user_id, product_name, productor) VALUES (1, 'p1', 'DX');
INSERT INTO order_info (user_id, product_name, productor) VALUES (2, 'p1', 'WHH');
INSERT INTO order_info (user_id, product_name, productor) VALUES (2, 'p5', 'WL');
INSERT INTO order_info (user_id, product_name, productor) VALUES (3, 'p3', 'MA');
INSERT INTO order_info (user_id, product_name, productor) VALUES (4, 'p1', 'WHH');
INSERT INTO order_info (user_id, product_name, productor) VALUES (6, 'p1', 'WHH');
INSERT INTO order_info (user_id, product_name, productor) VALUES (9, 'p8', 'TE');

二、explain 输出解释

mysql> explain select * from user_info;
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
| id | select_type | table     | type | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      | user_info | ALL  | NULL          | NULL | NULL    | NULL |   10 |       |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------+

expain出来的信息有10列，分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra,下面对这些字段出现的可能进行解释：

列名

描述

id

执行编号，标识select所属的行。如果在语句中没子查询或关联查询，

只有唯一的select，每行都将显示1

否则，内层的select语句一般会顺序编号，对应于其在原始语句中的位置

select_type

显示本行是简单或复杂select。如果查询有任何复杂的子查询，

则最外层标记为PRIMARY（DERIVED、UNION、UNION RESUlT）

table

访问引用哪个表（引用某个查询，如“derived3”）

type

数据访问/读取操作类型

（ALL、index、range、ref、eq_ref、const/system、NULL）

possible_keys

此次查询中可能选用的索引

key

此次查询中确切使用到的索引.

key_len

显示mysql在索引里使用的字节数

ref

哪个字段或常数与 key 一起被使用

rows

显示此查询一共扫描了多少行. 这个是一个估计值.

Extra

额外信息，如using index、filesort等

id

id是用来顺序标识整个查询中SELELCT 语句的，在嵌套查询中id越大的语句越先执行。该值可能为NULL，如果这一行用来说明的是其他行的联合结果。

select_type

select_type 表示了查询的类型, 它的常用取值有:

  • SIMPLE, 表示此查询不包含 UNION 查询或子查询
  • PRIMARY, 表示此查询是最外层的查询
  • UNION, 表示此查询是 UNION 的第二或随后的查询
  • DEPENDENT UNION, UNION 中的第二个或后面的查询语句, 取决于外面的查询
  • UNION RESULT, UNION 的结果
  • SUBQUERY, 子查询中的第一个 SELECT
  • DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果.

最常见的查询类别应该是 SIMPLE 了, 比如当我们的查询没有子查询, 也没有 UNION 查询时, 那么通常就是 SIMPLE 类型, 例如:

mysql> explain select * from user_info where id = 2;
+----+-------------+-----------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table     | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-----------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | user_info | const | PRIMARY       | PRIMARY | 8       | const |    1 |       |
+----+-------------+-----------+-------+---------------+---------+---------+-------+------+-------+

如果我们使用了 UNION 查询, 那么 EXPLAIN 输出 的结果类似如下:

mysql> explain select * from user_info where id = 1 union select * from user_info where id = 2;
+----+--------------+------------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type  | table      | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+--------------+------------+-------+---------------+---------+---------+-------+------+-------+
|  1 | PRIMARY      | user_info  | const | PRIMARY       | PRIMARY | 8       | const |    1 |       |
|  2 | UNION        | user_info  | const | PRIMARY       | PRIMARY | 8       | const |    1 |       |
| NULL | UNION RESULT | <union1,2> | ALL   | NULL          | NULL    | NULL    | NULL  | NULL |       |
+----+--------------+------------+-------+---------------+---------+---------+-------+------+-------+

table

表示查询涉及的表或衍生表

  • 关联优化器会为查询选择关联顺序，左侧深度优先
  • 当from中有子查询的时候，表名是derivedN的形式，N指向子查询，也就是explain结果中的下一列
  • 当有union result的时候，表名是union 1,2等的形式，1,2表示参与union的query id

注意：MySQL对待这些表和普通表一样，但是这些“临时表”是没有任何索引的

type

type显示的是访问类型，它提供了判断查询是否高效的重要依据依据,通过 type 字段, 我们判断此次查询是 全表扫描 还是 索引扫描 等.

type 常用类型：

1）system

表中只有一条数据. 这个类型是特殊的 const 类型.

2）const

针对主键或唯一索引的等值查询扫描, 最多只返回一行数据. const 查询速度非常快, 因为它仅仅读取一次即可.

例如下面的这个查询, 它使用了主键索引, 因此 type 就是 const 类型的.

mysql> explain select * from user_info where id = 2;
+----+-------------+-----------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table     | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-----------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | user_info | const | PRIMARY       | PRIMARY | 8       | const |    1 |       |
+----+-------------+-----------+-------+---------------+---------+---------+-------+------+-------+

3）eq_ref

此类型通常出现在多表的 join 查询, 表示对于前表的每一个结果, 都只能匹配到后表的一行结果. 并且查询的比较操作通常是 =, 查询效率较高.

例如:

mysql> EXPLAIN SELECT * FROM user_info, order_info WHERE user_info.id = order_info.user_id;
+----+-------------+------------+--------+---------------------------+---------------------------+---------+-------------------------+------+-------------+
| id | select_type | table      | type   | possible_keys             | key                       | key_len | ref                     | rows | Extra       |
+----+-------------+------------+--------+---------------------------+---------------------------+---------+-------------------------+------+-------------+
|  1 | SIMPLE      | order_info | index  | user_product_detail_index | user_product_detail_index | 254     | NULL                    |    9 | Using index |
|  1 | SIMPLE      | user_info  | eq_ref | PRIMARY                   | PRIMARY                   | 8       | test.order_info.user_id |    1 |             |
+----+-------------+------------+--------+---------------------------+---------------------------+---------+-------------------------+------+-------------+

4）ref

此类型通常出现在多表的 join 查询, 针对于非唯一或非主键索引, 或者是使用了 最左前缀 规则索引的查询.

例如下面这个例子中, 就使用到了 ref 类型的查询:

mysql> EXPLAIN SELECT * FROM user_info, order_info WHERE user_info.id = order_info.user_id AND order_info.user_id = 5;
+----+-------------+------------+-------+---------------------------+---------------------------+---------+-------+------+--------------------------+
| id | select_type | table      | type  | possible_keys             | key                       | key_len | ref   | rows | Extra                    |
+----+-------------+------------+-------+---------------------------+---------------------------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | user_info  | const | PRIMARY                   | PRIMARY                   | 8       | const |    1 |                          |
|  1 | SIMPLE      | order_info | ref   | user_product_detail_index | user_product_detail_index | 9       | const |    1 | Using where; Using index |
+----+-------------+------------+-------+---------------------------+---------------------------+---------+-------+------+--------------------------+

5）range

表示使用索引范围查询, 通过索引字段范围获取表中部分数据记录. 这个类型通常出现在 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, IN() 操作中.

当 type 是 range 时, 那么 EXPLAIN 输出的 ref 字段为 NULL, 并且 key_len 字段是此次查询中使用到的索引的最长的那个.

例如：

mysql> explain select * from user_info where id between 1 and 8;

+----+-------------+-----------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table     | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+-----------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | user_info | range | PRIMARY       | PRIMARY | 8       | NULL |    8 | Using where |
+----+-------------+-----------+-------+---------------+---------+---------+------+------+-------------+

例子：

在where后面使用范围，如果该列不是主键（普通索引、唯一索引）则索引不起作用，如果是组合索引那么索引会被利用
单独在user_id 上加上普通索引

mysql> explain select o.p_name,u.name from order_info o left join user_info u on o.user_id = u.id where u.id > 2;
+----+-------------+-------+--------+---------------+---------+---------+----------------+------+-------------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref            | rows | Extra       |
+----+-------------+-------+--------+---------------+---------+---------+----------------+------+-------------+
|  1 | SIMPLE      | o     | ALL    | NULL          | NULL    | NULL    | NULL           |    9 | Using where |
|  1 | SIMPLE      | u     | eq_ref | PRIMARY       | PRIMARY | 8       | test.o.user_id |    1 | Using where |
+----+-------------+-------+--------+---------------+---------+---------+----------------+------+-------------+


#给order_info增加组合索引u_pname_p(user_id,p_name,p)则索引能利用上

mysql> explain select o.p_name,u.name from order_info o left join user_info u on o.user_id = u.id where u.id > 2;
+----+-------------+-------+--------+---------------+-----------+---------+----------------+------+--------------------------+
| id | select_type | table | type   | possible_keys | key       | key_len | ref            | rows | Extra                    |
+----+-------------+-------+--------+---------------+-----------+---------+----------------+------+--------------------------+
|  1 | SIMPLE      | o     | range  | u_pname_p     | u_pname_p | 9       | NULL           |    4 | Using where; Using index |
|  1 | SIMPLE      | u     | eq_ref | PRIMARY       | PRIMARY   | 8       | test.o.user_id |    1 | Using where              |
+----+-------------+-------+--------+---------------+-----------+---------+----------------+------+--------------------------+

6）index

表示全索引扫描(full index scan), 和 ALL 类型类似, 只不过 ALL 类型是全表扫描

而 index 类型则仅仅扫描所有的索引, 而不扫描数据.

index 类型通常出现在: 所要查询的数据直接在索引树中就可以获取到（这种一般指的是innodb引擎）, 而不需要扫描数据. 当是这种情况时, Extra 字段 会显示 Using index.

mysql> EXPLAIN SELECT name FROM  user_info;
+----+-------------+-----------+-------+---------------+------------+---------+------+------+-------------+
| id | select_type | table     | type  | possible_keys | key        | key_len | ref  | rows | Extra       |
+----+-------------+-----------+-------+---------------+------------+---------+------+------+-------------+
|  1 | SIMPLE      | user_info | index | NULL          | name_index | 152     | NULL |   10 | Using index |
+----+-------------+-----------+-------+---------------+------------+---------+------+------+-------------+

上面的例子中, 我们查询的 name 字段恰好是一个索引, 因此我们直接从索引中获取数据就可以满足查询的需求了, 而不需要查询表中的数据. 因此这样的情况下, type 的值是 index, 并且 Extra 的值是 Using index.

7）ALL

表示全表扫描, 这个类型的查询是性能最差的查询之一. 通常来说, 我们的查询不应该出现 ALL 类型的查询, 因为这样的查询在数据量大的情况下, 对数据库的性能是巨大的灾难. 如一个查询是 ALL 类型查询, 那么一般来说可以对相应的字段添加索引来避免.

下面是一个全表扫描的例子, 可以看到, 在全表扫描时, possible_keys 和 key 字段都是 NULL, 表示没有使用到索引, 并且 rows 十分巨大, 因此整个查询效率是十分低下的.

mysql> EXPLAIN SELECT age FROM  user_info WHERE age = 20;
+----+-------------+-----------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table     | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | user_info | ALL  | NULL          | NULL | NULL    | NULL |   10 | Using where |
+----+-------------+-----------+------+---------------+------+---------+------+------+-------------+

通常来说, 不同的 type 类型的性能关系如下:

ALL < index < range ~ index_merge < ref < eq_ref < const < system

  • ALL 类型因为是全表扫描, 因此在相同的查询条件下, 它是速度最慢的.
  • index 类型的查询虽然不是全表扫描, 但是它扫描了所有的索引, 因此比 ALL 类型的稍快.

后面的几种类型都是利用了索引来查询数据, 因此可以过滤部分或大部分数据, 因此查询效率就比较高了.

一般来说，得保证查询至少达到range级别，最好能达到ref。

possible_keys

possible_keys 表示 MySQL 在查询时, 能够使用到的索引. 注意, 即使有些索引在 possible_keys 中出现, 但是并不表示此索引会真正地被 MySQL 使用到. MySQL 在查询时具体使用了哪些索引, 由 key 字段决定.

key

key列显当前查询时所真正使用到的索引.。

如果没有选择索引，键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

key_len

表示查询优化器使用了索引的字节数. 这个字段可以评估组合索引是否完全被使用, 或只有最左部分字段被使用到.

key_len 的计算规则如下:

  • 字符串
    • char(n): n 字节长度
    • varchar(n): 如果是 utf8 编码, 则是 3 n + 2字节; 如果是 utf8mb4 编码, 则是 4 n + 2 字节.
  • 数值类型:
    • TINYINT: 1字节
    • SMALLINT: 2字节
    • MEDIUMINT: 3字节
    • INT: 4字节
    • BIGINT: 8字节
  • 时间类型
    • DATE: 3字节
    • TIMESTAMP: 4字节
    • DATETIME: 8字节
  • 字段属性: NULL 属性 占用一个字节. 如果一个字段是 NOT NULL 的, 则没有此属性.

key_len列显示MySQL决定使用的键长度。如果键是NULL，则长度为NULL。使用的索引的长度。在不损失精确性的情况下，长度越短越好 。

举个例子：

mysql> EXPLAIN SELECT * FROM order_info WHERE user_id < 3 AND product_name = 'p1' AND productor = 'WHH';
+----+-------------+------------+-------+---------------------------+---------------------------+---------+------+------+--------------------------+
| id | select_type | table      | type  | possible_keys             | key                       | key_len | ref  | rows | Extra                    |
+----+-------------+------------+-------+---------------------------+---------------------------+---------+------+------+--------------------------+
|  1 | SIMPLE      | order_info | range | user_product_detail_index | user_product_detail_index | 9       | NULL |    4 | Using where; Using index |
+----+-------------+------------+-------+---------------------------+---------------------------+---------+------+------+--------------------------+

上面的例子是从表 order_info 中查询指定的内容, 而我们从此表的建表语句中可以知道, 表 order_info 有一个联合索引:

KEY `user_product_detail_index` (`user_id`, `product_name`, `productor`)

不过此查询语句 WHERE user_id < 3 AND product_name = 'p1' AND productor = 'WHH' 中, 因为先进行 user_id 的范围查询, 而根据 最左前缀匹配 原则, 当遇到范围查询时, 就停止索引的匹配。

因此实际上我们使用到的索引的字段只有 user_id, 因此在 EXPLAIN 中, 显示的 key_len 为 9. 因为 user_id 字段是 BIGINT, 占用 8 字节, 而 NULL 属性占用一个字节, 因此总共是 9 个字节. 若我们将user_id 字段改为 BIGINT(20) NOT NULL DEFAULT '0', 则 key_length 应该是8.

上面因为 最左前缀匹配 原则, 我们的查询仅仅使用到了联合索引的 user_id 字段, 因此效率不算高.

再例如：

mysql>  EXPLAIN SELECT * FROM order_info WHERE user_id = 1 AND product_name = 'p1';
+----+-------------+------------+------+---------------------------+---------------------------+---------+-------------+------+--------------------------+
| id | select_type | table      | type | possible_keys             | key                       | key_len | ref         | rows | Extra                    |
+----+-------------+------------+------+---------------------------+---------------------------+---------+-------------+------+--------------------------+
|  1 | SIMPLE      | order_info | ref  | user_product_detail_index | user_product_detail_index | 161     | const,const |    2 | Using where; Using index |
+----+-------------+------------+------+---------------------------+---------------------------+---------+-------------+------+--------------------------+

这次的查询中, 我们没有使用到范围查询, key_len 的值为 161. 为什么呢? 因为我们的查询条件 WHERE user_id = 1 AND product_name = 'p1' 中, 仅仅使用到了联合索引中的前两个字段, 因此：

keyLen(user_id) + keyLen(product_name) = 9 + 50 * 3 + 2 = 161

ref

哪个字段或常数与 key 一起被使用

rows

rows 也是一个重要的字段. MySQL 查询优化器根据统计信息, 估算 SQL 要查找到结果集需要扫描读取的数据行数. 这个值非常直观显示 SQL 的效率好坏, 原则上 rows 越少越好.。注意这是一个预估值。

Extra

EXplain 中的很多额外的信息会在 Extra 字段显示, 常见的有以下几种内容:

1）Using filesort

当 Extra 中有 Using filesort 时, 表示 MySQL 需额外的排序操作, 不能通过索引顺序达到排序效果. 一般有 Using filesort, 都建议优化去掉, 因为这样的查询 CPU 资源消耗大.

例如：

mysql>  EXPLAIN SELECT * FROM order_info ORDER BY product_name;
+----+-------------+------------+-------+---------------+---------------------------+---------+------+------+-----------------------------+
| id | select_type | table      | type  | possible_keys | key                       | key_len | ref  | rows | Extra                       |
+----+-------------+------------+-------+---------------+---------------------------+---------+------+------+-----------------------------+
|  1 | SIMPLE      | order_info | index | NULL          | user_product_detail_index | 254     | NULL |    9 | Using index; Using filesort |
+----+-------------+------------+-------+---------------+---------------------------+---------+------+------+-----------------------------+
1 row in set (0.00 sec)

我们的索引是

KEY `user_product_detail_index` (`user_id`, `product_name`, `productor`)

但是上面的查询中根据 product_name 来排序, 因此不能使用索引进行优化, 进而会产生 Using filesort. 如果我们将排序依据改为 ORDER BY user_id, product_name, 那么就不会出现 Using filesort 了.

例如:

mysql> EXPLAIN SELECT * FROM order_info ORDER BY user_id, product_name;

+----+-------------+------------+-------+---------------+---------------------------+---------+------+------+-------------+
| id | select_type | table      | type  | possible_keys | key                       | key_len | ref  | rows | Extra       |
+----+-------------+------------+-------+---------------+---------------------------+---------+------+------+-------------+
|  1 | SIMPLE      | order_info | index | NULL          | user_product_detail_index | 254     | NULL |    9 | Using index |
+----+-------------+------------+-------+---------------+---------------------------+---------+------+------+-------------+
1 row in set (0.00 sec)

如果对于利用组合索引进行排序，那么多个排序的顺序应该是一致的，否则还是会using filesort

mysql> explain select * from order_info order by user_id asc,p_name asc ,p desc ;
+----+-------------+------------+-------+---------------+-----------+---------+------+------+-----------------------------+
| id | select_type | table      | type  | possible_keys | key       | key_len | ref  | rows | Extra                       |
+----+-------------+------------+-------+---------------+-----------+---------+------+------+-----------------------------+
|  1 | SIMPLE      | order_info | index | NULL          | u_pname_p | 255     | NULL |    6 | Using index; Using filesort |
+----+-------------+------------+-------+---------------+-----------+---------+------+------+-----------------------------+

必须是:

mysql> explain select * from order_info order by user_id desc,p_name desc ,p desc ;
+----+-------------+------------+-------+---------------+-----------+---------+------+------+-------------+
| id | select_type | table      | type  | possible_keys | key       | key_len | ref  | rows | Extra       |
+----+-------------+------------+-------+---------------+-----------+---------+------+------+-------------+
|  1 | SIMPLE      | order_info | index | NULL          | u_pname_p | 255     | NULL |    6 | Using index |
+----+-------------+------------+-------+---------------+-----------+---------+------+------+-------------+

2）Using index

"覆盖索引扫描", 表示查询在索引树中就可查找所需数据, 不用扫描表数据文件, 往往说明性能不错

3）Using temporary

查询有使用临时表, 一般出现于排序, 分组和多表 join 的情况, 查询效率不高, 建议优化.

4）Distinct

MySQL发现第1个匹配行后,停止为当前的行组合搜索更多的行。

5）Not exists

MySQL能够对查询进行LEFT JOIN优化,发现1个匹配LEFT JOIN标准的行后,不再为前面的的行组合在该表内检查更多的行。

6）Using where

WHERE 子句用于限制哪一个行匹配下一个表或发送到客户。

7）Using sort_union(...), Using union(...), Using intersect(...)

这些函数说明如何为index_merge联接类型合并索引扫描

8）range checked for each record (index map: #)

MySQL没有发现好的可以使用的索引,但发现如果来自前面的表的列值已知,可能部分索引可以使用。

勤天
关注
  • 4
    点赞
  • 踩
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MySql中如何使用 explain 查询 SQL 的执行计划
09-09
explain命令是查看查询优化器如何决定执行查询的主要方法。这篇文章重点给大家介绍MySql中如何使用 explain 查询 SQL 的执行计划，感兴趣的朋友一起看看吧
Explain执行计划
m0_70299172的博客
05-03 1480
一条查询语句在经过MySQL查询优化器的各种基于成本和规则的优化会后生成一个所谓的执行计划，这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。EXPLAIN语句来帮助我们查看某个查询语句的具体执行计划，我们需要搞懂EPLATNEXPLAIN的各个输出项都是干嘛使的，从而可以有针对性的提升我们查询语句的性能。通过使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。
Explain 执行计划详解
weixin_47184173的博客
05-30 6895
什么是执行计划 我们往往通过慢查询日志，可以找到慢查询的sql具体是怎么写的。我们往往可以通过表的索引，执行引擎等等去自己判断sql为什么执行缓慢的原因。但是这明显不是高效的。 我们的MySQL中为我们提供了EXPLAN关键字来协助我们分析SQL。 一条查询语句在经过 MySQL 查询优化器的各种基于成本和规则的优化会后生成一个所谓的执行计划，这个执行计划展示了接下来具体执行查询的方式，比如多表连接的顺序是什么，对于每个表采用什么访问方法来具体执行查询等等。EXPLAIN 语句来帮助我们查看某个查询语
SQL优化之EXPLAIN执行计划（转载）
最新发布
baomingshu的博客
04-08 820
友情提醒:先看文章目录，大致了解文章知识点结构，点击文章目录可直接跳转到文章指定位置。
一文详解 Explain 执行计划
weixin_44121790的博客
02-23 698
详解MySQL Explain执行计划
【进阶】explain 执行计划详解
yhl_jxy的博客
03-17 3897
前言 MySql使用explain关键字可以模拟优化器执行sql语句，我们就能够知道MySql会如何处理咱们的sql， 可以根据explain的分析结果和MySql底层数据结构优化sql。文章内容基于MySql 5.7.24分析， 不同MySql版本可能有差别。如果用的是MySql 5.6.X，差别应该不会很大。 MySql索引底层数据结构和算法：https://blog.csdn.net...
SQL - Explain查看SQL执行计划
MinggeQingchun的博客
08-22 1624
我们在工作中肯定写过，也会进行一下sql语句的优化，在优化sql语句里看过相应的在进行sql语句优化的时候，理解执行计划中各个参数的意思，弄明白执行的顺序，对sql优化有很大的帮助。1、通过命令查看执行计划2、通过Navicat查看执行计划在Navicat中执行完相应的sql语句，然后点击【解释】，其实执行计划就是解释怎么执行的sql语句，有的版本的“解释”按钮在上面，有的版本的“解释”按钮在下面，视版本不同而定我们来看下执行计划中各个参数的意思。
MySQL中通过EXPLAIN如何分析SQL的执行计划详解
12-16
在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。 下面分别对EXPLAIN命令结果的每一列进行说明： .select_type:表示SELECT的类型，常见...
MySQL，通过explain分析低效SQL的执行计划。
12-14
目录 结果列说明： select_type：SELECT、SIMPLE（简单表，即不使用表连接和子查询）、PRIMARY（主查询，即外层的查询）、UNION（union中的第二个或后面的查询语句）、... 执行SQL： EXPLAIN select * from bs_demo
【MySQL系列】- Explain执行计划详解
记录总结工作过往
05-03 1492
EXPLAIN关键字是MySQL性能分析神器；可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的，分析你的查询语句或是表结构的性能瓶颈。
图灵学院：用 Explain 查看 SQL 的执行计划
秀岩的博客
06-29 2499
一、Explain 概述 Explain 含义及作用 二、Explain 返回列详解 id 列、select_type 列、table 列、partitions 列、type 列、possible_keys 列、key 列、key_len 列、ref 列、rows列、Extra列
Explain详解与索引最佳实践
qq_27740127的博客
06-15 1091
mysql执行计划explain结果里的key有使用索引，如果select后面查询的字段都可以从这个索引的树中获取，这种情况一般可以说是用到了覆盖索引，extra里一般都有using index；覆盖索引一般针对的是辅助索引，整个查询结果只通过辅助索引就能拿到结果，不需要通过辅助索引树找到主键(即不需要回表)，再通过主键去主键索引树里获取其它字段值。
使用Explain查看执行计划
xxxbbb000的博客
12-06 1659
explain执行查询计划
使用Mysql Explain 查询sql执行计划
凡夫编程
11-20 2703
最近运维反馈生产环境产生了大量的慢sql，开发的同事在改这些慢sql的时候，我发现开发的同事纯粹是为了完成开发任务，在写sql的时候，极少用explain，或者不明白explain的意义在哪。这篇文章，我将和大家分享，为什么在上线一个sql前要用explain和explain执行计划结果信息的解读explain的命令很简单，但explain背后的mysql优化器可并不简单，可以说是mysql最复杂的存在了。不过没关系，只要掌握好explain输出各字段的含义，对于普通的开发者来说，至少不用加班改慢sql了。
MySQL基础学习: 第四章 使用EXPLAIN查看执行计划详解分析
玉汝于成
01-13 1211
这里的id相同表示着：通过查询优化器对查询语句的优化，将子查询语句转变成了连接查询语句。在一个查询语句中可能包含多个小的查询语句，在MySQL中每个小的查询语句都包含select_type属性，通过该属性的取值，我们可以判断出这个小的查询语句在整个查询语句中扮演着一个什么样的角色。在存在UNION的查询语句中如果各个子查询语句间存在依赖关系，者除了第一个记录的select_type为PRIMARY，其他的子查询语句记录中的select_type为DEPENDENT UNION。
Explain执行计划详解
IT王小二的博客
01-24 3107
作者：IT王小二 博客：https://itwxe.com 一条查询 SQL 语句为什么会执行很慢？执行的时候走了什么索引？多表查询的时候 SQL 大体执行流程是怎么样的？Explain 执行计划详解给各位客官一一道来。 一、示例MySQL安装方式和版本 首先需要 MySQL 安装的客官看这两篇，小二演示使用的是 Docker 的安装方式： Linux(CentOS7)下二进制安装MySQL5.7.26 Docker搭建MySQL并挂载数据 小二安装完的 MySQL 数据库版本为 5.7.36。 二.
MySQL优化——Explain分析执行计划详解
爱吃鸡腿的明仔
03-27 2329
在应用的的开发过程中，由于初期数据量小，开发人员写 SQL 语句时更重视功能上的实现，但是当应用系统正式上线后，随着生产数据量的急剧增长，很多 SQL 语句开始逐渐显露出性能问题，对生产的影响也越来越大，此时这些有问题的 SQL 语句就成为整个系统性能的瓶颈，因此我们必须要对它们进行优化，本章将详细介绍在 MySQL中优化 SQL 语句的方法。当面对一个有 SQL 性能问题的数据库时，我们应该从何处入手来进行系统的分析，使得能够尽快定位问题 SQL 并尽快解决问题。
根据Explain查看sql执行计划,对SQL进行优化
ggjklncffd的博客
06-27 661
1.使用Explain关键字查看SQL的执行计划语句为：EXPLAIN "你的sql语句" 而后根据上图查出来的sql执行计划主要关注两点1.Type是否全表查询 ALL代表全表查询，2.关注rows 查看扫描了多少行（估算值），两者既可判定是否需要优化2.确定该sql是需要优化的使用 show index from tableName(表名)查看该表使用了哪些索引，以免索引创建冲突3.结合前两次操作判断在哪个字段上面使用索引，建议是在where条件后面的字段添加索引，但是有一点需要特别注意：状态字段
mysql explain执行计划详解
z_ruitao的博客
08-28 386
1）、id列数字越大越先执行，如果说数字一样大，那么就从上往下依次执行，id列为null的就表是这是一个结果集，不需要使用它来进行查询。 2）、select_type列常见的有： A：simple：表示不需要union操作或者不包含子查询的简单select查询。有连接查询时，外层的查询为simple，且只有一个 B：primary：一个需要union操作或者含有子查询的select，位于最外层的...
explain查看sql执行计划
02-29
在SQL中，EXPLAIN是一个用于查看SQL执行计划的关键字。它可以帮助我们了解数据库是如何执行我们的查询语句的，以及查询语句的性能优化方面的问题。 当我们在数据库中执行一条SQL查询语句时，数据库系统会根据查询...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值