MySQL执行计划分析实战：从实例场景出发深度解读各项参数与分析步骤

引言：

在MySQL数据库优化中，理解和分析SQL执行计划是一项至关重要的技能。通过执行计划，我们可以洞察MySQL如何执行SQL查询，以及它选择索引、决定查询顺序和计算行数的方式。本文将通过一个实例场景，详细阐述MySQL执行计划的各项参数含义，并手把手带你走过分析执行计划的完整步骤。

一、实例场景

假设我们有一个电商订单表orders，结构如下：

CREATE TABLE orders (id INT AUTO_INCREMENT PRIMARY KEY,customer_id INT NOT NULL,product_id INT NOT NULL,order_date DATE,amount DECIMAL(10,2),INDEX idx_customer_product (customer_id, product_id)
);

现在有一条SQL查询语句：

EXPLAIN SELECT * FROM orders WHERE customer_id = 123 AND product_id = 456;

二、MySQL执行计划分析

首先，我们通过EXPLAIN关键字执行这条查询语句以获取执行计划：

EXPLAIN SELECT * FROM orders WHERE customer_id = 123 AND product_id = 456;

执行计划结果可能会类似如下：

+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+----------------+
| id | select_type | table  | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra          |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+----------------+
| 1  | SIMPLE      | orders | NULL       | const | idx_customer_product | idx_customer_product | 8       | const,const | 1    | 100.00   | Using index; |
+----+-------------+--------+------------+-------+---------------+---------+---------+-------+------+----------+----------------+

三、执行计划参数解析

id：执行计划的序列号，代表查询的执行顺序。在本例中，id为1，表示这是一个简单查询，无需额外的子查询或联合查询。
select_type：查询类型。SIMPLE表示这是个简单查询，没有子查询或UNION操作。
table：执行此查询涉及到的表名。
partitions：分区信息，若表被分区则会显示具体分区信息，本例中为空，表示未分区。
type：访问类型，反映了MySQL如何访问表数据。const表示MySQL已经通过索引找到了确切的一行数据，是最理想的访问类型。
possible_keys：可能用到的索引列表，本例中显示idx_customer_product，表明MySQL在评估查询时认为这个索引可能被用到。
key：实际使用的索引，本例中为idx_customer_product，表示MySQL确实选择了这个复合索引执行查询。
key_len：索引中使用的字节数，表示索引使用的大小。
ref：用于查找索引项的列或常量。本例中为const,const，表示customer_id和product_id都是通过常量来进行比较。
rows：MySQL根据统计信息估算的需要检查的行数，本例中为1，说明MySQL通过索引找到了确切的一行记录。
filtered：MySQL估计的行过滤比例，本例中为100%，意味着所有通过索引选取的行都会满足WHERE条件。
Extra：额外信息，本例中的Using index表示MySQL使用了覆盖索引，无需访问表数据就能获取所需信息。

四、执行计划分析步骤

观察执行顺序（id）：理解SQL语句的执行流程，特别是当存在嵌套查询或JOIN操作时。
分析访问类型（type）：判断MySQL如何获取数据，理想情况下应尽量接近system、const、eq_ref、ref等高效访问类型。
检查实际使用的索引（key）：确认MySQL是否选择了预期的索引，并分析为何选择或未选择某个索引。
评估MySQL的估算（rows和filtered）：如果MySQL对行数的估算与实际相差较大，可能需要重新统计表信息或优化查询条件。
解读Extra信息：理解MySQL额外执行的操作，例如是否使用了覆盖索引、排序、临时表等。