WordPress页面加载缓慢但MySQL慢查询日志无记录，该排查哪些方向？

• 确认慢查询日志是否真正启用
  执行SHOW VARIABLES LIKE '%slow_query_log%';检查slow_query_log状态是否为ON，同时确认slow_query_log_file的路径是否正确、文件是否具备写入权限。有时候重启后配置没生效，可能是my.cnf里的配置写错了位置（比如放在了[mysqld]区块之外）。

• 检查是否有未被统计的语句类型
  默认慢查询日志不会记录管理类语句（如OPTIMIZE TABLE、ALTER TABLE）和存储过程内部的语句，可临时设置log_slow_admin_statements = ON和log_slow_slave_statements = ON（如果是从库），开启这些语句的日志记录，排查是否是这类操作拖慢了页面。

• 排查单条查询耗时短但执行次数过多的情况
  单条查询耗时0.4秒虽然没触发0.5秒的阈值，但页面加载时如果执行了上百次这类查询，总耗时会被拉高。可以用SHOW PROCESSLIST;实时查看当前运行的查询，或者临时开启general_log（注意别长期开启，会占用大量磁盘空间）统计所有查询的执行次数和总耗时。

• 检查锁等待与事务阻塞
  页面慢可能是查询被锁阻塞，而非查询本身慢。执行SHOW ENGINE INNODB STATUS;查看事务锁等待情况，或者查询INFORMATION_SCHEMA.INNODB_LOCKS、INFORMATION_SCHEMA.INNODB_LOCK_WAITS表，确认是否有长时间持锁的事务阻塞了后续请求。

• 排查应用层或网络问题

  • 页面加载慢可能是应用代码逻辑问题，比如循环查询数据库、未做缓存，或者应用服务器本身资源不足（CPU、内存占满）；
  • 测试应用服务器到MySQL服务器的网络延迟，用ping或traceroute查看往返时间，排查是否存在网络丢包或延迟过高的情况。

• 确认long_query_time设置是否生效
  执行SHOW VARIABLES LIKE 'long_query_time';确认当前值是否为0.5，有些情况重启后配置没生效，比如仅用动态命令设置但没写入配置文件，或者配置被其他优先级更高的配置覆盖。

• 检查MySQL服务器资源瓶颈

  • CPU使用率过高：可能存在大量复杂计算的查询（如排序、分组）；
  • 内存不足：检查innodb_buffer_pool_size配置是否合理，内存不足会导致频繁换页；
  • 磁盘IO过高：可能是全表扫描过多，或者磁盘本身性能不足（比如机械硬盘瓶颈），可以用系统工具（如iostat）查看磁盘读写情况。

• 排查存储引擎后台操作
  比如InnoDB的后台刷新脏页、合并插入缓冲等操作，可能占用大量资源导致前台查询变慢。通过SHOW ENGINE INNODB STATUS;查看BUFFER POOL AND MEMORY和INSERT BUFFER AND ADAPTIVE HASH INDEX部分的指标，判断是否是后台操作引发的问题。

内容的提问来源于stack exchange，提问作者Shawn