如何在小型项目中开启MySQL慢查询日志并定位慢SQL-mysql教程-PHP中文网

直接执行SHOW VARIABLES LIKE 'slow_query_log';，返回ON才算真正开启；若为OFF，即使配置文件已设置也需SET GLOBAL slow_query_log = 'ON'或重启MySQL。

如何在小型项目中开启mysql慢查询日志并定位慢sql

怎么确认 MySQL 慢查询日志当前是否开启

直接查 slow_query_log 变量最可靠，别靠猜或看配置文件就下结论：

登录 MySQL 后执行 SHOW VARIABLES LIKE 'slow_query_log';，返回 ON 才算真开启
slow_query_log_file 告诉你日志写到哪，常见默认是 /var/lib/mysql/hostname-slow.log，但可能被改过
注意：即使 my.cnf 里写了 slow_query_log = 1，如果 MySQL 是运行中改的配置且没执行 SET GLOBAL slow_query_log = ON;，实际仍不生效

如何临时开启慢查询日志（开发/排查用）

小型项目不需要重启 MySQL，用动态变量就能开，但得有 SUPER 权限：

先设阈值：SET GLOBAL long_query_time = 1;（单位秒，设成 1 表示记录耗时 ≥1s 的查询）
再开日志：SET GLOBAL slow_query_log = ON;
指定日志路径（可选）：SET GLOBAL slow_query_log_file = '/tmp/mysql-slow.log';，避免写到磁盘空间紧张的分区
⚠️ 注意：long_query_time 设为 0 会记录所有查询，对小项目压力不小；设为 0.1 虽能抓更细的慢 SQL，但 MySQL 5.7+ 才支持小数，旧版本只认整数

怎么看慢查询日志里的 SQL 并识别真正瓶颈

日志不是越长越有用，重点看三块：时间戳、Query_time、SQL 本身。别被 Lock_time 或 Rows_sent 迷惑：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

用 mysqldumpslow 快速聚合（比如 mysqldumpslow -s t -t 5 /tmp/mysql-slow.log 查最耗时前 5 条）
手动看日志时，紧盯 # Query_time: 2.345678 后面那条 SQL，它才是真实执行语句；前面的 # User@Host 和 # Schema 帮你定位来源
常见假慢：SQL 看着简单但 Rows_examined: 500000，说明没走索引；或者 Lock_time: 1.9 占了大头，其实是锁等待而非执行慢
别直接在生产库上 EXPLAIN 日志里的 SQL——参数可能不同，最好复制到测试环境，用相同数据量和条件复现

为什么开了日志却没写入任何内容

最常踩的坑不是配置错，而是「查询根本没进慢日志的判定逻辑」：

MySQL 默认只记录“已执行完”的查询，如果连接断了、SQL 被 KILL、或者客户端超时退出，这条记录不会进慢日志
log_queries_not_using_indexes 是独立开关，即使关了慢日志也能单独开它，但它的输出不归类到 slow log 文件，而是混在 general log 里（如果开了的话）
检查权限：运行 SET GLOBAL 的账号必须有 SUPER 权限；如果是云数据库（如阿里云 RDS），很多变量禁止动态修改，只能提工单或改参数模板
Linux 下还要看文件权限：ls -l /tmp/mysql-slow.log，确保 MySQL 进程用户（通常是 mysql）有写权限，否则静默失败

慢查询日志本身不分析 SQL，它只负责“录下来”。真正卡在哪，得结合 EXPLAIN 输出、表索引状态、以及 Rows_examined 和 Query_time 的比值来交叉判断——尤其当 Query_time 高但 Rows_examined 很低时，问题大概率出在锁、网络或应用层重试逻辑上。