做网站构建手机一键优化

一、执行计划核心字段总览

字段名	人类语言解释	性能影响等级
type	数据访问方式	★★★★★
key	实际使用索引	★★★★☆
rows	预估扫描行数	★★★★☆
Extra	附加执行信息	★★★★☆
key_len	使用索引的长度	★★★☆☆

二、关键字段深度拆解

1. type（访问类型）——查询性能的晴雨表

性能从优到劣排序：
system > const > eq_ref > ref > fulltext > range > index > ALL

典型场景分析：

-- 最优情况：主键查询
EXPLAIN SELECT * FROM users WHERE id = 1;
-- type: const-- 最差情况：全表扫描
EXPLAIN SELECT * FROM orders WHERE amount > 100;
-- type: ALL

2. key_len（索引使用长度）——索引利用率的检测仪

计算公式：
索引字段长度 × 字段数 + 预留字节

计算示例：

CREATE TABLE `demo` (`id` INT(11) NOT NULL,`name` VARCHAR(20) DEFAULT NULL,`age` TINYINT(4) DEFAULT NULL,INDEX `idx_name_age` (`name`,`age`)
);-- 查询1：使用完整索引
EXPLAIN SELECT * FROM demo WHERE name='张三' AND age=25;
-- key_len = 20*3+1 + 1 = 62-- 查询2：仅使用name列
EXPLAIN SELECT * FROM demo WHERE name='李四';
-- key_len = 20*3+1 = 61

3. Extra（附加信息）——隐藏的性能杀手

常见值解析：

值	含义	处理建议
Using index	使用覆盖索引	保持当前优化
Using temporary	使用临时表	检查GROUP BY/ORDER BY字段
Using filesort	文件排序	添加合适索引
Using where	存储引擎返回后过滤	检查索引是否完整
Select tables optimized away	优化器已优化（如MIN/MAX查询）	无需处理

三、全字段详解速查表

字段名	含义	常见值示例
id	查询序列号	1, 2（联合查询时数值不同）
select_type	查询类型	SIMPLE, PRIMARY, SUBQUERY
table	访问的表名	users, orders
partitions	匹配的分区	p0, p1
type	访问方式	const, ref, ALL
possible_keys	可能使用的索引	idx_name, PRIMARY
key	实际使用的索引	idx_age
key_len	使用索引的长度	4, 62
ref	索引引用关系	const, db1.users.id
rows	预估扫描行数	1, 10024
filtered	存储引擎返回数据后，经过过滤剩余的比例	100.00
Extra	附加执行信息	Using index, Using temporary

四、性能诊断四步法

第一步：检查type等级

- ✅ 目标：至少达到range级别
- ❌ 问题：出现ALL时需要紧急优化
- 💡 处理：添加合适索引

第二步：验证索引使用

-- 检查实际使用索引是否最优
SHOW INDEX FROM users;

第三步：分析扫描行数

- 当rows > 10000时：可能存在全表扫描
- 优化案例：100万行表查询从2s优化到0.02s

第四步：排查Extra警告

1. 发现Using filesort → 检查ORDER BY字段是否匹配索引
2. 出现Using temporary → 优化GROUP BY字段
3. 存在Using where → 检查查询条件是否完整使用索引

五、经典优化案例

案例1：索引失效分析

-- 原始查询（type: ALL）
EXPLAIN SELECT * FROM orders WHERE YEAR(create_time)=2023;-- 优化方案：改为范围查询
EXPLAIN SELECT * FROM orders 
WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31';
-- type提升为range

案例2：覆盖索引优化

-- 原始查询（Extra: NULL）
EXPLAIN SELECT user_id FROM comments WHERE post_id=100;-- 创建覆盖索引
ALTER TABLE comments ADD INDEX idx_post_user(post_id,user_id);
-- Extra显示Using index

六、高级分析技巧

1. JSON格式查看详细成本

EXPLAIN FORMAT=JSON 
SELECT * FROM products WHERE price > 100;
-- 查看"cost_info"字段

2. 索引长度验证公式

VARCHAR(n)：n*3+2
INT：4
TINYINT：1
DATETIME：5
允许NULL的字段：+1

3. 执行计划可视化工具推荐

1. MySQL Workbench执行计划可视化
2. Percona Toolkit的pt-visual-explain
3. JetBrains DataGrip的图形化展示

七、常见问题解决方案

症状	原因	解决方案
type=ALL	无可用索引	添加WHERE条件涉及的索引
Using filesort	排序字段不匹配索引	创建复合索引包含排序字段
key_len过短	未充分使用复合索引	检查查询条件顺序
rows数值异常	统计信息过期	执行ANALYZE TABLE
filtered=100	存储引擎层未过滤数据	检查索引覆盖情况