标签：8.0 rows explain id cost analyze payment staff
原文地址：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中会枚举出来标访问时候每种可能性。
标签：8.0,rows,explain,id,cost,analyze,payment,staff 来源： https://www.cnblogs.com/wy123/p/12984774.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。