直接执行SHOW VARIABLES LIKE 'slow_query_log';，返回ON才算真正开启；若为OFF，即使配置文件已设置也需SET GLOBAL slow_query_log = 'ON'或重启MySQL。
怎么确认 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 很低时，问题大概率出在锁、网络或应用层重试逻辑上。
