MySQL慢查询日志需在服务端开启，通过SET GLOBAL或my.cnf配置slow_query_log、slow_query_log_file和long_query_time；PHP无法直接开启，只能调用mysqldumpslow解析或埋点监控执行时长。
MySQL 慢查询日志怎么开，开在哪
PHP 本身不记录慢 SQL，真正起作用的是 MySQL 的 slow_query_log。它必须在数据库服务端开启，PHP 只能读日志或配合触发告警。
常见错误是以为在 PHP 里配个 ini_set('mysql.trace_mode', 1) 就能抓慢查询——这根本不存在，mysql.trace_mode 是过时且无效的伪配置。
- 确认 MySQL 版本 ≥ 5.1，执行
SHOW VARIABLES LIKE 'slow_query_log%';查看当前状态 - 动态开启：运行
SET GLOBAL slow_query_log = ON;（重启后失效） - 永久生效：在
my.cnf的[mysqld]段加两行：slow_query_log = ONslow_query_log_file = /var/log/mysql/mysql-slow.log -
long_query_time = 1表示记录执行超 1 秒的语句（支持小数，如0.5）
注意：/var/log/mysql/ 目录需确保 MySQL 进程有写权限，否则日志静默失败，连报错都不会打。
PHP 如何安全地读取并解析慢查询日志
直接用 fopen() 读 /var/log/mysql/mysql-slow.log 很危险——文件可能被 MySQL 轮转（rename），也可能因权限问题打不开；更关键的是，日志格式非标准 JSON/CSV，每条记录跨多行，靠 file() 按行切会断章取义。
立即学习“PHP免费学习笔记（深入）”；
推荐做法是用 MySQL 自带工具 mysqldumpslow 预处理：
- 命令行跑一次：
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log（按总耗时排序，取前 10 条） - PHP 中调用：
shell_exec('mysqldumpslow -s t -t 5 /var/log/mysql/mysql-slow.log 2>&1') - 务必加
2>&1，否则错误（比如权限拒绝）会被吞掉，返回空字符串，你以为没慢 SQL，其实只是读失败了 - 不要用
exec()或system()，它们对输出截断敏感；shell_exec()更稳妥
如果必须自己解析，记住：每条慢查询以 # Time: 开头，结尾是空行；# User@Host: 和 # Query_time: 是关键标记行，不能只 grep SELECT。
如何在 PHP 请求中实时捕获单条 SQL 超时
慢日志只能事后分析，无法定位“这次请求卡在哪条 SQL”。要实现运行时监控，得在 PDO 或 MySQLi 执行前埋点，结合 microtime(true) 测时长。
关键不是“记录”，而是“不拖垮主流程”——超时检测逻辑必须轻量、无阻塞、不依赖外部服务：
- 用
set_time_limit(0)禁用脚本超时（避免和 SQL 超时冲突） - 执行前记时间：
$start = microtime(true);，执行后算差值：$elapsed = microtime(true) - $start; - 判断阈值别写死，建议从环境变量读：
getenv('DB_QUERY_TIMEOUT_MS') ?: 800 - 记录方式优先写本地文件（
error_log()），别一上来就发 HTTP 到监控系统——网络抖动会导致整个请求 hang 住 - 注意事务上下文：如果在事务里某条 SQL 超时，后续 rollback 可能也慢，要单独测 rollback 耗时
示例片段：
$stmt = $pdo->prepare("SELECT * FROM orders WHERE user_id = ?");<br>$start = microtime(true);<br>$stmt->execute([$uid]);<br>$elapsed = (microtime(true) - $start) * 1000;<br>if ($elapsed > (int)getenv('DB_QUERY_TIMEOUT_MS')) {<br> error_log(sprintf('[SLOW SQL] %.2fms: %s', $elapsed, $stmt->queryString));<br>}
为什么 SHOW PROCESSLIST 抓不到真正的慢查询
SHOW PROCESSLIST 只显示“当前正在运行”的连接状态，但绝大多数慢查询实际已执行完、只留下锁或结果集等待 PHP fetch——这时它早已从 processlist 消失，你看到的全是 Sleep 或 Waiting for table metadata lock，毫无价值。
更隐蔽的问题是：某些 ORM（如 Laravel Eloquent）默认用 PDO::ATTR_EMULATE_PREPARES = true，导致 EXPLAIN 和真实执行计划不一致，你在开发环境 EXPLAIN 很快，线上却慢，因为预处理被模拟了，索引没走对。
- 检查是否启用真预处理：
$pdo->getAttribute(PDO::ATTR_EMULATE_PREPARES)返回false才可靠 -
SHOW PROFILE FOR QUERY N已废弃，MySQL 8.0+ 请改用performance_schema的events_statements_history_long表 - 不要依赖
mysqli_get_client_info()判断客户端能力——它只报版本，不反映实际行为
最常被忽略的一点：慢查询日志默认不记录管理语句（如 SELECT SLEEP(2)），除非显式设置 log_slow_admin_statements = ON，而这类语句恰恰是压测或误操作的重灾区。
