如何查看执行计划

在需要分析的查询语句前直接加上 EXPLAIN 关键字即可：

EXPLAIN SELECT * FROM users WHERE age = 30;

在执行计划的输出中，重点关注以下几个指标：

• type：访问类型（如 ALL 代表全表扫描，ref 代表使用非唯一索引扫描）。
• key：实际决定使用的索引。
• rows：优化器估算需要扫描的行数。

索引对执行计划的影响

假设存在一个用户表 users。 未建索引时的执行计划：

EXPLAIN SELECT * FROM users WHERE age = 30;

• 表现：type 为 ALL（全表扫描），key 为 NULL，rows 的数值接近整张表的记录数。 创建索引后的执行计划：

CREATE INDEX idx_age ON users(age);
EXPLAIN SELECT * FROM users WHERE age = 30;

• 表现：type 提升为 ref（或 const/range），key 显示为 idx_age，同时 rows 显著降低，通常仅为个位数或极小值。
• 结论：索引的存在使数据库能够避免低效的全表扫描，转而通过索引树进行快速定位，大幅降低了扫描的数据量。

AND 条件的先后次序对执行计划是否有影响

对比以下两条除了条件顺序外完全相同的查询语句： 查询 A：

EXPLAIN SELECT * FROM users WHERE age = 30 AND name = 'Alice';

查询 B：

EXPLAIN SELECT * FROM users WHERE name = 'Alice' AND age = 30;

• 执行计划表现：这两条语句生成的执行计划（包括 type、possible_keys、key、rows 等）在绝大多数情况下是完全一致的。
• 原因：现代关系型数据库（如 MySQL、PostgreSQL）内部都拥有基于成本的查询优化器（CBO）。优化器在真正执行 SQL 之前，会对查询进行解析和重写。它会参考表的统计信息，自动选择过滤效果最好的路径，而不会受用户在 WHERE 子句中书写 AND 条件先后顺序的影响。
• 结论：在现代数据库中，AND 条件的先后次序对执行计划没有影响。开发人员在编写此类查询时，应优先考虑代码的可读性与维护性。