MySQL查询优化是提升数据库整体性能的重要手段，当业务数据量增长或者并发请求增多时，低效的查询语句会直接拖慢系统响应速度，甚至引发数据库服务压力过大。合理的查询优化可以从根源上减少不必要的资源消耗，提升数据访问效率。
查询优化的核心思路
查询优化的本质是让数据库用最小的成本拿到需要的数据，核心围绕减少扫描数据量、避免无效计算、合理利用缓存三个方向展开。我们可以通过分析查询执行过程，找到性能瓶颈点针对性优化。
1. 分析查询执行计划
执行计划是数据库执行查询语句前的规划方案，通过EXPLAIN命令可以查看语句的执行细节，判断是否存在全表扫描、索引失效等问题。以下是查看执行计划的基础用法：
-- 查看查询语句的执行计划 EXPLAIN SELECT user_id, user_name FROM user_info WHERE age > 18;
执行结果中需要重点关注type字段，常见取值的性能从好到差依次为：system > const > eq_ref > ref > range > index > ALL。如果type为ALL说明是全表扫描，需要优先优化。
2. 合理设计和使用索引
索引是提升查询效率最有效的手段，但是错误的索引设计反而会拖慢性能。设计索引时需要注意以下原则：
- 优先给查询条件、连接条件、排序和分组字段创建索引
- 避免创建过多冗余索引，冗余索引会占用额外存储空间，还会降低写入性能
- 联合索引要遵循最左前缀匹配原则，把区分度高的字段放在前面
- 不要在索引列上做函数运算或者类型转换，会导致索引失效
以下是创建联合索引的示例：
-- 给user_info表的age和create_time字段创建联合索引 CREATE INDEX idx_age_create_time ON user_info(age, create_time);
3. 优化SQL语句本身
很多低效查询是SQL语句写法不合理导致的，以下是常见的优化技巧：
- 避免使用
SELECT *，只查询需要的字段，减少数据传输和解析开销 - 尽量用
UNION ALL代替UNION，UNION会做去重操作，增加额外消耗 - 避免使用子查询，尽量把子查询改写为关联查询，减少临时表的创建
- 合理限制查询结果数量，大分页查询可以用延迟关联优化，避免深度分页带来的性能问题
以下是深度分页的优化示例，普通分页查询在偏移量很大时性能很差：
-- 普通深度分页查询，性能较差 SELECT id, user_name FROM user_info ORDER BY id LIMIT 100000, 10; -- 优化后的延迟关联分页查询 SELECT t.id, t.user_name FROM user_info t INNER JOIN (SELECT id FROM user_info ORDER BY id LIMIT 100000, 10) tmp ON t.id = tmp.id;
4. 其他辅助优化手段
除了上述核心方法，还有一些辅助优化技巧可以配合使用：
- 定期更新表统计信息，让优化器能生成更准确的执行计划，执行
ANALYZE TABLE 表名即可更新 - 合理利用查询缓存，对于重复度高、更新频率低的查询可以开启查询缓存减少重复计算
- 避免在查询条件中使用
OR，如果OR连接的字段不是都有索引，会导致全表扫描，可以改写为UNION查询
优化效果验证
每次优化后都需要重新通过EXPLAIN查看执行计划，同时对比优化前后的查询耗时，确认优化方案有效。如果优化后性能没有提升，需要重新分析执行过程，排查是否还有其他瓶颈点。
查询优化不是一次性的工作，随着业务数据量变化和业务逻辑调整，需要定期回顾慢查询日志，持续迭代优化方案，才能长期保持数据库的高效运行。