需先确认 MySQL 慢查询日志已启用：执行 SHOW VARIABLES LIKE 'slow_query_log'，若为 OFF 则需在 my.cnf 的 [mysqld] 段配置 slow_query_log = ON 并重启；PHP 8.5 不产生慢日志，仅可能触发慢 SQL。
怎么确认 MySQL 慢查询日志真的在记录
PHP 8.5 本身不产生慢查询日志，它只是可能触发慢 SQL；真正记录慢查询的是 MySQL 服务。很多人查了半天 php.ini 或 opcache 配置，结果日志根本没开——方向错了。
先连上 MySQL 执行：
SHOW VARIABLES LIKE 'slow_query_log';如果返回
OFF，那日志压根没启用，PHP 再怎么优化也没用。
-
slow_query_log = ON必须设在 MySQL 配置文件（如/etc/mysql/my.cnf）的[mysqld]段下，重启生效 -
long_query_time = 1.0是阈值（单位秒），PHP 8.5 下建议从0.5开始调，避免漏掉真实瓶颈 -
log_output = FILE（默认）或TABLE（写入mysql.slow_log），后者方便用 SQL 查，但需确保log_output包含TABLE - 注意：MySQL 8.0+ 默认关闭
log_queries_not_using_indexes，如需分析未走索引的查询，得手动打开
PHP 8.5 环境下怎么看慢查询对应哪段代码
MySQL 日志只记 SQL 和时间，不带 PHP 调用栈。想定位到具体文件行号，得靠「SQL 注释 + 应用层打点」配合。
在 PDO 或 mysqli 执行前，给 SQL 加上可识别的注释，比如：
$sql = "/* user_profile_load, line 42 */ SELECT * FROM users WHERE id = ?";这样在慢日志里就能搜
user_profile_load 快速关联业务逻辑。
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖
debug_backtrace()动态拼注释——PHP 8.5 中高频调用会明显拖慢性能 - 框架用户（如 Laravel）可复用
DB::listen()回调，在 SQL 执行超时（如 >300ms）时主动写入自定义日志，附带debug_print_backtrace(false, 2)截取关键帧 - 注意 MySQL 的
max_allowed_packet：过长的注释（尤其含中文或堆栈）可能被截断，导致匹配失败
分析 slow.log 时最常误读的三类时间字段
MySQL 慢日志里 # Time:、# User@Host: 后面的时间、以及 Query_time: 不是同一回事，混用会导致归因错误。
-
# Time:是语句**开始执行**的时间戳（UTC），不是记录时间；跨时区部署时，和 PHPdate('c')对不上是正常的 -
Query_time:是 MySQL 内核实际执行耗时（不含网络传输、排队等待），但**不包含锁等待时间**；如果看到Query_time: 0.000123却业务卡顿，大概率是行锁/表锁阻塞，得查information_schema.INNODB_TRX -
Lock_time:是获取锁的耗时，值大说明并发冲突严重；PHP 8.5 的短生命周期请求容易放大这个影响，尤其是用PDO::ATTR_EMULATE_PREPARES = true时，prepare 阶段也可能抢锁
PHP 8.5 + MySQL 8.0 组合下的特殊坑
PHP 8.5 默认用 MySQLi 或 PDO MySQL 8.0+ 驱动，某些旧分析脚本（比如用正则硬切日志字段）会失效，因为 MySQL 8.0.22+ 日志格式加了微秒精度和额外字段。
- 老式日志解析器若按空格分割
Query_time: 0.123456，会把0.123456当成独立字段，而新格式是Query_time: 0.123456 Lock_time: 0.000123，中间多一个空格 - PHP 8.5 的 JIT 编译对简单 SQL 分析无加速效果，反而可能让
preg_match()解析日志变慢——别在慢日志处理链路里用复杂正则 - MySQL 8.0 的哈希连接（Hash Join）可能让原本慢的 JOIN 突然变快，但日志里仍显示
Using join buffer，别直接当成优化成功，得看EXPLAIN FORMAT=TREE确认是否真用了 Hash Join
慢查询日志不是终点，是起点；真正难的是把 Query_time 和 PHP 请求生命周期里的其他耗时（DNS、TLS、OPcache 验证、autoload 文件 I/O）剥离开——这些不会出现在 slow.log 里，但它们经常比 SQL 本身更拖后腿。
