原文地址：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中会枚举出来标访问时候每种可能性。