MySQL SQL调优实战：从慢查询到高性能

1. MySQL SQL调优的核心价值与场景定位

每次接手性能卡顿的MySQL数据库时，我总会先检查慢查询日志。上周刚处理过一个电商平台的案例：某商品列表页SQL执行耗时从平时的200ms暴涨到8秒，导致高峰期页面超时率骤增。通过调优最终将响应时间控制在150ms内——这正是SQL调优的价值体现。

SQL调优本质是通过改写查询语句、调整数据库结构或优化执行计划，使数据库用最少资源消耗获取所需数据的过程。主要适用于三类典型场景：

• 查询响应时间超过业务容忍阈值（如API要求500ms内返回）
• 数据库服务器出现异常负载（CPU持续90%以上）
• 特定SQL语句消耗过多IO或内存资源

在用户感知层面，调优效果往往立竿见影。某社交平台的私信功能优化后，消息加载时间从3秒降至300毫秒，用户留存率提升了17%。但要注意：调优不是银弹，当遇到硬件瓶颈或架构缺陷时，需要配合扩容或重构解决。

2. 调优前的必备诊断工具

2.1 慢查询日志实战配置

在my.cnf中开启慢查询日志是最基础的诊断手段：

sql复制slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1  # 超过1秒的查询
log_queries_not_using_indexes = 1  # 记录未走索引的查询

最近处理过一个物流系统案例：通过日志发现一条UPDATE语句平均执行2.3秒，检查发现其WHERE条件涉及3个未索引字段。添加复合索引后降至0.1秒。

2.2 EXPLAIN执行计划详解

分析下面这个订单查询：

sql复制EXPLAIN SELECT * FROM orders 
WHERE user_id = 100 AND status = 'paid'
ORDER BY create_time DESC;

关键指标解读：

• type列：从ALL（全表扫描）优化到ref/range级别
• rows列：预估扫描行数从10万降到200行
• Extra列：避免出现"Using filesort"或"Using temporary"

我曾将某报表查询的type从index_merge优化到const，执行时