要开启并利用mysql慢查询日志进行性能优化，首先需在配置文件中设置slow_query_log=1、指定slow_query_log_file路径、调整long_query_time阈值、启用log_queries_not_using_indexes，之后重启或动态加载配置；日志记录包括query_time、lock_time、rows_sent、rows_examined等关键信息，用于分析sql效率；优化方向包括添加索引、避免select *、拆分复杂查询、优化join操作，并定期清理日志及使用工具辅助分析；同时注意结合业务判断sql是否需要优化、避免盲目加索引、检查日志权限问题以及建议在生产环境长期开启。
MySQL慢查询日志是排查数据库性能问题的重要工具之一，尤其在面对高并发、响应延迟等情况时，通过分析慢查询日志可以快速定位效率低下的SQL语句。开启并合理利用这个功能，对数据库优化非常有帮助。
一、如何开启慢查询日志？
开启慢查询日志需要修改MySQL的配置文件（通常是
my.cnf或
my.ini），主要涉及以下几个参数：
slow_query_log：是否开启慢查询日志，设置为1表示开启。
slow_query_log_file：指定慢查询日志的存储路径和文件名。
long_query_time：设定“慢”的标准，单位是秒，默认是10秒。可以根据实际需求调整，比如设成0.5。
log_queries_not_using_indexes：是否记录未使用索引的查询，建议开启。
示例配置如下：
[mysqld] slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 0.5 log_queries_not_using_indexes = 1
修改后重启MySQL服务生效，或者执行以下命令动态开启（适用于临时测试）：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.5; SET GLOBAL log_queries_not_using_indexes = ON;
二、慢查询日志里都记录了什么？
查看慢查询日志的内容，通常会看到类似下面的信息：
# Time: 230910 14:30:00 # User@Host: root[root] @ localhost [] # Query_time: 1.234567 Lock_time: 0.000000 Rows_sent: 100 Rows_examined: 10000 SET timestamp=1694346600; SELECT * FROM orders WHERE user_id = 123;
关键字段说明：
Query_time：查询耗时，这是判断SQL是否“慢”的核心指标。
Lock_time：等待锁的时间，如果很高可能意味着表锁竞争严重。
Rows_sent：返回的数据行数。
Rows_examined：扫描的数据行数，这个值远大于返回行数时，说明SQL效率不高，可能是缺少索引或条件不精准。
这些信息能帮你判断到底是查询本身写得不好，还是结构设计有问题。
三、如何通过慢查询日志做性能优化？
有了慢查询日志之后，下一步就是分析内容，并针对性地优化。常见的优化方向包括：
添加合适的索引
如果某条SQL频繁出现在日志中，且
Rows_examined很大，考虑在WHERE或JOIN字段上加索引。
**避免SELECT ***
只取需要的字段，减少数据传输压力，也更容易命中覆盖索引。
拆分复杂查询
把一个大查询拆成多个小查询，或者用缓存中间结果，降低单次查询负担。
优化JOIN操作
确保JOIN字段都有索引，尽量避免多表JOIN，尤其是全表扫描的JOIN。
定期清理慢查询日志
日志文件会越来越大，建议定期备份归档，防止磁盘占满或影响读取效率。
还可以借助一些工具辅助分析，比如
mysqldumpslow或第三方工具如pt-query-digest，它们可以帮助你统计出最常出现、最耗时的SQL语句。
四、常见误区与注意事项
不是所有慢查询都是问题
某些定时任务或后台统计SQL本来就慢，不能一概而论。要结合业务场景判断哪些SQL必须优化。
不要盲目加索引
索引虽然能提升查询速度，但会影响写入性能。而且过多索引会导致维护成本上升。
注意日志文件权限问题
MySQL进程是否有权限写入日志目录？如果开启失败，可以检查错误日志或文件权限。
生产环境建议长期开启
虽然会产生一定IO开销，但相比潜在的性能隐患，这点代价是值得的。
基本上就这些。慢查询日志是一个很实用的功能，只要正确开启并加以分析，就能发现不少隐藏的问题点。
