要优化mysql性能，慢查询日志是关键切入点。1. 开启慢查询日志可在配置文件中设置slow_query_log=1、指定日志路径、设定long_query_time（如1秒）并记录未使用索引的sql；也可在运行时用set global命令动态开启。2. 查看日志需关注query_time（执行耗时）、lock_time（锁等待时间）、rows_examined（扫描行数）和rows_sent（返回行数），这些指标反映sql性能状况。3. 常见慢查询原因包括：缺少合适索引导致全表扫描、索引使用不当（如对字段使用函数）、返回数据过多、join操作不合理。4. 优化建议包括添加索引、调整sql写法、限制返回数据量、优化join逻辑，并通过explain分析执行计划。5. 推荐使用mysqldumpslow、pt-query-digest等工具辅助分析日志，结合可视化平台实现监控与趋势分析，从而持续优化sql性能。
在MySQL性能优化中，慢查询日志是最基础、也最直接的切入点。很多数据库问题其实都藏在慢查询里，只要打开这个开关，就能看到“卡顿”的源头。这篇文章讲的是怎么用好慢查询日志，从开启到分析再到优化，一步步带你理清思路。
如何开启并配置慢查询日志？
想看慢查询日志，首先得让它记录下来。默认情况下，MySQL是不开启这项功能的。你可以通过修改配置文件（通常是my.cnf或my.ini）来启用：
slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = 1
上面几个参数的意思分别是：
- 开启慢查询日志
- 指定日志路径
- 设置超过1秒的SQL为“慢”
- 记录未使用索引的查询
改完配置记得重启MySQL服务或者重新加载配置。如果你不想重启，也可以在运行时动态设置：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL log_queries_not_using_indexes = 'ON';
注意：有些系统上动态修改long_query_time后可能需要断开当前连接才会生效。
怎么看懂慢查询日志的内容？
慢查询日志的格式其实挺直观的。一条典型的日志长这样：
# Time: 2025-04-05T10:00:01.123456Z # User@Host: root[root] @ localhost [] # Query_time: 2.123456 Lock_time: 0.000123 Rows_sent: 1 Rows_examined: 100000 SET timestamp=1717581601; SELECT * FROM orders WHERE user_id = 12345;
重点看这几个指标：
- Query_time：整个查询耗时，单位秒。这是判断是否“慢”的关键。
- Lock_time：等待锁的时间，如果很高，可能是表锁竞争严重。
- Rows_examined：扫描了多少行数据。数值大说明没走好索引。
- Rows_sent：实际返回给客户端的数据行数。如果和扫描行数差很多，说明做了大量无效过滤。
有时候你会看到Rows_examined很大但Query_time却不高，这可能是因为用了缓存（比如query cache），但这不是长久之计，还是得优化SQL本身。
常见慢查询原因及优化建议
慢查询的成因多种多样，但最常见的几种情况如下：
✅ 缺少合适的索引
一个没有索引的where条件，可能导致全表扫描。比如下面这个语句：
SELECT * FROM users WHERE email = 'test@example.com';
如果email字段没有索引，那每次执行都要扫全表。解决办法很简单：加索引。
ALTER TABLE users ADD INDEX idx_email (email);
✅ 索引使用不当
有时虽然加了索引，但SQL写法不对，导致索引失效。例如：
SELECT * FROM orders WHERE DATE(created_at) = '2025-04-01';
这里用了函数处理字段，会让索引失效。应该改成范围查询：
SELECT * FROM orders WHERE created_at >= '2025-04-01' AND created_at < '2025-04-02';
✅ 查询返回太多数据
有时候一个SQL返回了几千条甚至几万条数据，不仅慢还占资源。这时候要考虑是不是真的需要这么多数据，能不能分页？能不能加条件限制？
✅ 关联表太多或关联方式不对
多表JOIN时如果没有合理使用索引，或者JOIN顺序不合理，也可能拖慢速度。建议：
- 尽量减少JOIN数量
- 被驱动表的JOIN字段要有索引
- 使用EXPLAIN查看执行计划，看看有没有Using filesort或临时表
工具推荐：让分析更高效
光靠看日志效率太低，可以用一些工具辅助分析：
-
mysqldumpslow：MySQL自带的慢日志分析工具，能统计出现频率高的慢SQL。
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
上面命令按时间排序，显示前10条慢SQL。
-
pt-query-digest（Percona Toolkit的一部分）：比mysqldumpslow强大很多，支持聚合分析、输出报告等，适合做定期巡检。
-
可视化平台：像Prometheus + Grafana配合mysqld_exporter，可以实时监控慢查询趋势；有些公司也会自建慢查询分析平台，统一收集和展示。
基本上就这些。慢查询日志看似简单，但真要分析到位并不容易。关键是养成定期检查的习惯，结合日志和执行计划去定位问题。很多时候优化一条SQL，性能提升就能立竿见影。
评论（已关闭）
评论已关闭