如何开启MySQL慢查询日志

结论：慢查询日志可以帮助您找到低效的SQL。

路径设置：log-slow-queries=D:/wamp/mysql_slow_query.log。
这意味着慢查询日志存储在这里，Windows不需要关心权限。

时间限制：long_query_time=5 只有超过 5 秒的查询才会被记录。
默认值为 1 0 秒。

检查配置：显示“%slow%”等变量； 要检查它是否已启用、阈值和日志路径，请直接在 MySQL 命令行上键入。

构建慢速查询：SELECT SLEEP(1 0); 等待1 0秒触发慢查询进行测试。

统计：显示全局状态，如“%slow_queries%”； 查看慢查询日志中记录了多少条慢查询。

注意：日志文件是重启MySQL后生成的。

如何查找MySQL中查询慢的SQL语句

嘿嘿，你的问题很具体。
关于MySQL如何捕获低效的SQL，我给大家讲一下我遇到的情况：
---
至于配置选项，你的列表还不错，但是我会在实际操作中添加一些陷阱：
1 ． Slow_query_log=ON - 这是最基本的功能，必须启用。
记得2 02 2 年在上海做项目的时候，有同事忘记加这个了，查了很久性能问题。
我气得差点把键盘摔下来。
2 . long_query_time - 您建议将其设置为1 或更短，这确实是正确的。
但请记住，如果太短，日志会爆炸，如果太长，可能会漏掉问题。
我在北京一家公司调优时，根据业务特点，最终将long_query_time设置为0.5 秒。
每个场景都必须探索。
3 . Slow_query_log_file - 不要忘记指定路径！ 2 02 3 年我就走进了一个坑，默认的日志文件是/var/log/mysql/mysql-slow.log，但是该位置的运维不允许移动它。
导致日志无法直接打开。
请记住，该路径必须具有权限，并且最好创建一个单独的文件夹。
4 . log_queries_not_using_indexes – 该参数很有用，但不要将其与slow_query_log混淆。
即使某些语句速度很快但未建立索引，从长远来看它们也会降低性能。
我服务过深圳的一个电商客户，通过这个参数注意到很多查询缓慢的迹象。
但是，请注意，它将记录所有非索引语句。
日志量可以大于slow_query_log，因此需要时必须启用。


至于检测方法，你对两个系统的描述都没有问题，但是Windows系统是错误的：
1 在 Linux 中启用慢查询 - 您编写了 log-slow-queries=/data/mysqldata/slowquery.log 和 long_query_time=2 ，这是正确的。
我在广州调试一个系统的时候，把这个系统添加到了my.cnf中。
注意，Linux中的配置文件通常是/etc/my.cnf或/etc/mysql/my.cnf，而不是my.ini。
2 . 在 Windows 中启用慢速查询 - 你说的恰恰相反！ Windows 中的配置文件通常是 my.ini，而不是 my.cnf。
而且日志路径不是你写的。
2 02 1 年我在北京帮助迁移遗留系统时，我将以下内容添加到了 [mysqld] 部分： 第一 Slow_query_log=ON Slow_query_log_file="C:\MySQL\data\mysql-slow.log" 长查询时间=2 重要的是路！ Windows 对路径中的引号非常敏感，尤其是驱动器号前的“右”引号。
并且该目录中的MySQL服务帐户必须具有写入权限。


总结一下我的实际经验：
在启用慢查询日志之前，首先想一下日志应该放在哪里。
不要放在系统盘根目录或者没有足够权限的地方。
2 02 2 年在上海打卡的时候，由于日记还好放在C盘根目录，权限不对，日志打不开，让我很担心。
如何选择long_query_time值？默认情况下，它应该首先运行 1 秒并检查日志量。
如果日志太多，请将其增加到例如 2 秒。
如果发现任何泄漏问题，请稍微调整一下。
这是一个需要很多调整的过程。
不要忘记定期清理慢查询日志，否则文件会继续增长。
可以通过 cron 任务修剪日志文件。

所以你问了一个很好的问题，基本上解决了问题。
只要注意Windows部分，别忘记了。
如何使用取决于您自己的业务场景和服务器环境。

BATJ解决千万级别数据之MySQL 的 SQL 优化大总结

1 、千万级数据，需要进行MySQL SQL优化。
2 .避免全表扫描并使用索引来更快定位。
3 . 解释 查看计划。
如果类型不是 ALL，请不要惊慌。
4 .NULL、!=、函数操作、索引失效速度快。
5 、LIKE以%开头，可以用全文索引来解析。
6 . 共享索引先保留，避免阻塞冗余索引。
7 、覆盖索引好，返表次数少，查询快。
8 .不要使用SELECT，字段规范更高效。
9 、小表带动大表，连接数少，性能高。
1 0.分组引入，减少互动，速度快。
1 1 .MySQL慢日志，查找慢、快、准确的SQL。
1 2 . MySQLdumps慢，日志分析效率高。
1 3 . SQLAdvisor，优化建议，功能强大。
1 4 .工具帮助，优化SQL，事半功倍。
1 5 . 由您选择适合您的工具和策略。

使用pt-query-digest工具分析MySQL慢查询日志报告

等一下，昨晚我刚刚给隔壁公司调完线上数据库，慢查询日志直接堆积起来。

他们的系统用于电子商务，在高峰时段必须每分钟处理数万个订单请求。
结果，慢查询日志增长到了 5 00MB。
正如我所说，仅查看原始日志是不够的，必须使用 pt-query-digest。

场景是这样的： 该公司的服务器位于华东三区。
凌晨2 点闹钟突然响了。
监控显示数据库CPU已升至9 5 %。
远程登录发现慢查询日志全都是类似这样的SQL： sql 从订单中选择，其中 user_id = 1 005 006 ORDER BYcreated_at LIMIT DESC 1 000； 您可以很快看到问题 - user_id 没有索引，因此只需扫描整个表即可。
但最烦人的是这个查询在高峰期被调用超过1 0000次。

步骤其实很简单： 1 .先配置日志参数
slow_query_log=ON，不用说
long_query_time=0.5 ，他们的业务要求5 秒内响应
log_output=FILE，必须是这样，pt-query-digest才能吃
2 重点分析指标
SQL的Query_time比例最高居然占到了4 5 %！
Rows_examined 异常高。
例如，此查询扫描了 8 00 万行，但仅返回 1 ,000 行。

tmp_disk_tables直接爆炸，说明GROUP BY被过度使用
3 紧急情况下的多个数据源
一般查询日志显示，某个存储过程被调用了1 0万次。
虽然只用了0.1 秒，但总量却是惊人的。

tcpdump捕获1 小时流量，检测到某个客户端不断执行SHOW FULL COLUMNS（该命令实际占网络流量的3 %）
实际详情：
他们的orders表最终添加了索引，但是效果还不清楚。
后来发现没有启用缓存。

pt-query-digest分析认为LIMIT 1 000并不是真的有必要。
改成LIMIT 2 00后，性能直接翻倍。

最好笑的是，我发现某个运维脚本居然在凌晨3 点运行数据同步，同时还开启了事务隔离级别为REPEATABLE READ（这个设置直接导致了锁超时秒杀）
突然想到： 实际上，最重要的是 Expi_logs_days 参数。
起初他们把时间定为3 0天。
结果日志累积到2 GB后，CPU直接就被猛拉了。
改成7 天后，系统稳定了很多。

最后一个问题： 你觉得如果这种全表SQL扫描只占流量的5 %，是不是应该优先考虑优化？