专注,勤学,慎思。戒骄戒躁,谦虚谨慎

just do it

导航

MySQL 8.0中的 explain analyze(译)

原文地址:https://mysqlserverteam.com/mysql-explain-analyze/

 

MySQL 8.0.18刚刚发布(译者注:原文发表时间为October 17, 2019),它包含了一个全新的特性来分析和理解查询是如何执行的:explain analyze。

explain analyze是什么

EXPLAIN ANALYZE是一个查询分析工具,它会告诉你MySQL在查询上花了多少时间以及原因。它将计划查询、度量查询并执行查询,同时计算行数并测量在执行计划中不同阶段花费的时间。
当执行完成时,EXPLAIN ANALYZE将打印计划和度量结果,而不是查询结果。(译者注:直白地说就是,explain analyze会真是地执行当前的查询,返回的执行计划以及代价信息,但是不会返回查询自身的结果)

这个新特性是在常规的EXPLAIN查询计划检查工具之上构建的,可以看作是先前在MySQL 8.0中添加的explain forat = tree的扩展。
除了普通的explain将打印的查询计划和估计成本之外,explain analyze还将输出执行计划中单个迭代器的实际成本。

如何使用explain analyze

作为一个示例,我们将使用来自Sakila Sample数据库的数据和一个查询,该查询列出了每个员工在2005年8月完成的工作总量。这个问题很简单::

SELECT first_name, last_name, SUM(amount) AS total
FROM staff INNER JOIN payment
  ON staff.staff_id = payment.staff_id
     AND
     payment_date LIKE '2005-08%'
GROUP BY first_name, last_name;

+------------+-----------+----------+
| first_name | last_name | total    |
+------------+-----------+----------+
| Mike       | Hillyer   | 11853.65 |
| Jon        | Stephens  | 12218.48 |
+------------+-----------+----------+
2 rows in set (0,02 sec)

只有两个人,Mike和Jon,我们在2005年8月得到了他们每个人的总数,EXPLAIN FORMAT=TREE 将会显示执行计划和成本信息

 1 EXPLAIN FORMAT=TREE
 2 SELECT first_name, last_name, SUM(amount) AS total
 3 FROM staff INNER JOIN payment
 4   ON staff.staff_id = payment.staff_id
 5      AND
 6      payment_date LIKE '2005-08%'
 7 GROUP BY first_name, last_name;
 8 
 9 -> Table scan on <temporary>10     -> Aggregate using temporary table
11         -> Nested loop inner join  (cost=1757.30 rows=1787)
12             -> Table scan on staff  (cost=3.20 rows=2)
13             -> Filter: (payment.payment_date like '2005-08%')  (cost=117.43 rows=894)
14                 -> Index lookup on payment using idx_fk_staff_id (staff_id=staff.staff_id)  (cost=117.43 rows=8043)

但是它没有告诉我们这些估计是否正确,或者查询计划中的哪些操作实际花费了时间。 EXPLAIN ANALYZE可以做到这一点:

 1 EXPLAIN ANALYZE
 2 SELECT first_name, last_name, SUM(amount) AS total
 3 FROM staff INNER JOIN payment
 4   ON staff.staff_id = payment.staff_id
 5      AND
 6      payment_date LIKE '2005-08%'
 7 GROUP BY first_name, last_name;
 8 
 9 -> Table scan on <temporary>  (actual time=0.001..0.001 rows=2 loops=1)
10     -> Aggregate using temporary table  (actual time=58.104..58.104 rows=2 loops=1)
11         -> Nested loop inner join  (cost=1757.30 rows=1787) (actual time=0.816..46.135 rows=5687 loops=1)
12             -> Table scan on staff  (cost=3.20 rows=2) (actual time=0.047..0.051 rows=2 loops=1)
13             -> Filter: (payment.payment_date like '2005-08%')  (cost=117.43 rows=894) (actual time=0.464..22.767 rows=2844 loops=2)
14                 -> Index lookup on payment using idx_fk_staff_id (staff_id=staff.staff_id)  (cost=117.43 rows=8043) (actual time=0.450..19.988 rows=8024 loops=2)

这里有一些新的衡量方法:

  • 获取第一行的实际时间(毫秒)
  • 获取所有行的实际时间(以毫秒为单位)
  • 读取的实际行数
  • 实际循环次数

让我们看一个具体的例子,筛选迭代器的成本估计和实际度量,筛选迭代器选择了2005年8月的销售(上面的EXPLAIN ANALYZE输出中的第13行)。

Filter: (payment.payment_date like '2005-08%')
(cost=117.43 rows=894)
(actual time=0.464..22.767 rows=2844 loops=2)

过滤器的估计成本为117.43,估计返回894行,这些估计是查询优化器在执行查询之前根据可用的统计信息做出的。该信息也以EXPLAIN FORMAT=TREE输出的形式出现。
从循环数开,此筛选迭代器的循环次数为2。这是什么意思?要理解这个数字,我们必须查看查询计划中过滤迭代器上面的内容。
在第11行有一个嵌套循环联接,在第12行有一个对staff表的表扫描。
这意味着我们正在执行一个嵌套循环联接,其中我们扫描staff 表,对于该表中的每一行,我们使用索引查找和对付款日期进行筛选来查找付款表中相应的行。
因为staff表中有两行(Mike和Jon),我们对过滤和第14行上的索引查找进行了两次循环迭代。
对于很多人来说,EXPLAIN ANALYZE提供的一个有趣的信息是实际消耗时间,“0.464..22.767”,
这意味着读取第一行平均需要0.464 ms,读取所有行平均需要22.767 ms。
是平均值吗?是的,因为循环,我们必须对迭代器计时两次,报告的数字是所有循环迭代的平均值。
这意味着过滤的实际执行时间是这些数字的两倍,因此,如果我们查看在嵌套循环迭代器(第11行)中接收所有行所需的时间,它是46.135 ms,比一次运行过滤迭代器所需的时间多一倍多。


译者注:

这里的时间成本计算规律就是,每一步的执行时间,是包含了其子步骤的执行时间的之和,这几个步骤的时间包含关系是这样的:
Nested loop inner join这一层总的时间是58.104ms,也就是整各join的时间成本,包含了
“Table scan on staff表” 和 “payment表上的Filter的时间”
filter的时间又包含了:“index lookup”+“where条件filter条件”的时间,其中最耗时的就是index lookup这一步,也即数据查询的过程。
Index lookup 这一步的时间是19.988*2,乘以2意思是两次循环迭代,因此整个loop join过程的时间大部分都耗费在这个index lookup这个查找上,
平均每次(两次)Filter(22.767)= payment_date like '2005-08%'的筛选 + Index lookup on payment 查找(19.988)


实际读取的行数为2844,而估计值为894行。优化器漏掉了一个因子3(译者注:这一句话不太明白是什么意思,漏掉了什么)。
同样,由于循环的原因,估计的和实际的数字都是所有循环迭代的平均值。
如果我们查看表结构,payment_date列上没有索引或直方图,因此提供给优化器用于计算筛选器选择性的统计信息是有限的。
对于更好的统计信息会产生更准确的估计的示例,我们可以再次查看索引查找迭代器。我们看到索引提供了更精确的统计数据:8043行与8024行实际读取的比较。
这很好,出现这种情况是因为索引附带了额外的统计信息,而非索引列则没有。

那么你能利用这些信息做些什么呢?分析查询并理解为什么它们执行得不好需要一些实践。但一些简单的提示,让你开始:

  • 如果你想知道为什么花了这么长时间,看看时间,执行的时候时间都花费在哪一步?
  • 如果您想知道为什么优化器选择了该计划,请查看行计数器。估算的行数与实际的行数之间有很大的差异(即几个数量级或更多),这表明您应该仔细看一下。
    优化器根据估算值选择计划,但是查看实际执行情况可能会告诉您,另一个计划会更好。

如果您想知道优化器为什么选择该计划,请查看行计数器。巨大的差异。在估计的行数和实际行数之间的几个数量级或更多)是一个标志,表明您应该更仔细地查看它。
优化器根据估计值选择计划,但是查看实际执行情况可能会告诉您另一个计划会更好。

就是这样!MySQL查询分析工具箱中的另一个工具: 

  • 要检查查询计划:EXPLAIN FORMAT=TREE
  • 要跟踪查询执行:EXPLAIN ANALYZE
  • 要理解计划选择:Optimizer trace

我希望您喜欢这个新特性的快速浏览,解释分析将帮助您分析和理解慢速查询。

 

 

 


译者补充:

关于MySQL执行计划的几种展示方式,explain/explain format=tree/explain format=json/optimizer_trace
其实本质上都是一样的,只是详细程度不一样,对于explain analyze同时可以显式预估的+实际执行的信息,以下是将译文中使用的示例数据库导入到本地后,展示出来的一些信息,与上文中的信息稍有差异。
1,explain
最简洁或者粗略的执行计划显式方式,可以显式:表的访问方式、表之间的驱动顺序,以及Extra列中的其他信息,包括是否产生排序,使用临时表空间等等。
2,expalin format = tree
与explain analyze类似,同时包含了以预估的每一步的代价信息,仅仅是预估信息,并不包含实际执行信息

1 -> Table scan on <temporary>
2     -> Aggregate using temporary table
3         -> Nested loop inner join  (cost=1757.30 rows=1787)
4             -> Table scan on staff  (cost=3.20 rows=2)
5             -> Filter: (payment.payment_date like '2005-08%')  (cost=117.43 rows=894)
6                 -> Index lookup on payment using idx_fk_staff_id (staff_id=staff.staff_id)  (cost=117.43 rows=8043)

3,explain format = json
以json的格式显式与expalin format = tree的信息类似,说实话,可读性并不入expalin format = tree

 1 {
 2   "query_block": {
 3     "select_id": 1,
 4     "cost_info": {
 5       "query_cost": "1757.30"
 6     },
 7     "grouping_operation": {
 8       "using_temporary_table": true,
 9       "using_filesort": false,
10       "nested_loop": [
11         {
12           "table": {
13             "table_name": "staff",
14             "access_type": "ALL",
15             "possible_keys": [
16               "PRIMARY"
17             ],
18             "rows_examined_per_scan": 2,
19             "rows_produced_per_join": 2,
20             "filtered": "100.00",
21             "cost_info": {
22               "read_cost": "3.00",
23               "eval_cost": "0.20",
24               "prefix_cost": "3.20",
25               "data_read_per_join": "1K"
26             },
27             "used_columns": [
28               "staff_id",
29               "first_name",
30               "last_name"
31             ]
32           }
33         },
34         {
35           "table": {
36             "table_name": "payment",
37             "access_type": "ref",
38             "possible_keys": [
39               "idx_fk_staff_id"
40             ],
41             "key": "idx_fk_staff_id",
42             "used_key_parts": [
43               "staff_id"
44             ],
45             "key_length": "1",
46             "ref": [
47               "sakila.staff.staff_id"
48             ],
49             "rows_examined_per_scan": 8043,
50             "rows_produced_per_join": 1787,
51             "filtered": "11.11",
52             "cost_info": {
53               "read_cost": "145.50",
54               "eval_cost": "178.72",
55               "prefix_cost": "1757.30",
56               "data_read_per_join": "41K"
57             },
58             "used_columns": [
59               "payment_id",
60               "staff_id",
61               "amount",
62               "payment_date"
63             ],
64             "attached_condition": "(`sakila`.`payment`.`payment_date` like '2005-08%')"
65           }
66         }
67       ]
68     }
69   }
70 }

4,trace
set session optimizer_trace='enabled=ON';

explain sql
其实这些信息,都是跟explain format = json或者说explain analyze中,预估部分的一致的,这些数据都跟expalin format = tree一致,只不过trace中会枚举出来标访问时候每种可能性。

 

posted on 2020-05-29 22:45  MSSQL123  阅读(603)  评论(0编辑  收藏  举报