MySQL慢查询日志需在my.cnf的[mysqld]段配置slow_query_log=1、slow_query_log_file和long_query_time，重启MySQL生效；常见问题包括路径不存在、权限不足、SELinux限制及配置段错误；分析须用pt-query-digest而非mysqldumpslow；慢SQL优化先EXPLAIN，重点看type、key和Extra字段。
PHP 本身不记录“慢查询日志”，真正要开的是 MySQL 的慢查询日志。PHP 层的慢日志（如 slowlog）记录的是 PHP 脚本执行超时，不是 SQL 慢——这两者必须分清，否则排查方向全错。
MySQL 慢查询日志怎么启用（my.cnf 配置）
直接改 MySQL 配置文件，不是 PHP 的 php.ini。重点就三行，加在 [mysqld] 段下：
-
slow_query_log = 1—— 必须设为1，ON或TRUE在某些版本不认 -
slow_query_log_file = /var/log/mysql/slow.log—— 路径要有写权限，建议用绝对路径，别用~/或相对路径 -
long_query_time = 1—— 生产环境建议从1秒起步，压测或调试可临时设为0.5；设0会记录所有查询，磁盘撑爆风险高 - 顺手加上
log_queries_not_using_indexes = 1—— 即使没超时，但没走索引的也记下来，这类语句往往就是隐患
改完必须重启 MySQL：systemctl restart mysqld（CentOS/RHEL）或 service mysql restart（Ubuntu/Debian）。只 reload 不生效。
为什么开了却看不到日志？常见卡点
不是配置没写对，就是权限或路径被拦住了：
立即学习“PHP免费学习笔记（深入）”；
- 日志路径父目录不存在，比如
/var/log/mysql/目录没建，MySQL 不会自动创建，静默失败 - MySQL 进程用户（通常是
mysql）对日志文件或目录无写权限：ls -l /var/log/mysql/看属主，必要时chown mysql:mysql /var/log/mysql - SELinux 启用时（尤其 CentOS 7+），默认禁止 MySQL 写自定义路径，临时关掉验证：
setenforce 0；长期方案是打 SELinux 策略，不是关它 - 配置写到了错误段落，比如加在
[client]或[mysql]下——只有[mysqld]段才生效
验证是否真启用：mysql -e "SHOW VARIABLES LIKE 'slow_query_log';"，返回 ON 才算成功。
分析日志不能只靠 cat，得用 pt-query-digest
原生慢日志每条都带毫秒级时间戳、锁等待、扫描行数，但人眼根本没法快速定位瓶颈。用 pt-query-digest 是标准做法：
- 安装：
apt install percona-toolkit（Debian/Ubuntu）或brew install percona-toolkit（macOS） - 分析命令：
pt-query-digest /var/log/mysql/slow.log - 盯紧输出顶部的 Profile 表格：第一行
Rank就是拖累最狠的 SQL 模板，看它的Query_time（总耗时）和Rows_examined（扫描行数） - 如果
Rows_examined是几万甚至百万，但Rows_sent只有几十，基本就是缺索引或索引没命中
别信 mysqldumpslow 的聚合结果——它把 WHERE id = 123 和 WHERE id = 456 当成不同语句，而 pt-query-digest 能自动参数化，真正暴露共性问题。
查到慢 SQL 后，EXPLAIN 怎么看关键字段
拿到慢 SQL，别急着改代码，先跑一遍 EXPLAIN：
- 在 SQL 前加
EXPLAIN，例如：EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'paid' ORDER BY created_at DESC; - 重点看
type字段：ALL是全表扫描，range或ref才算走了索引；const最理想（主键等值查询） - 看
key列：显示实际使用的索引名；如果是NULL，说明没走索引，哪怕possible_keys里有候选 - 看
Extra列：出现Using filesort或Using temporary是严重信号，通常意味着ORDER BY或GROUP BY没命中索引顺序
特别注意：函数包裹字段会让索引失效，比如 WHERE YEAR(created_at) = 2025，必须改成 WHERE created_at >= '2025-01-01' AND created_at ；复合索引字段顺序不对（比如 <code>INDEX(a,b) 却只查 WHERE b = 1）也等于没建。
真正难的不是开日志或跑 EXPLAIN，而是把日志里的 SQL 模板和 PHP 代码里的具体调用位置对应上——没有上下文，优化就是闭门造车。最轻量的办法是在 PDO 执行前给 SQL 加注释，比如 /* dashboard_api */ SELECT ...，这样日志里一眼就能定位到哪个接口、哪行 PHP 代码触发的。
