WordPress/WooCommerce数据库查询过载，求助根源排查方案

一、根源定位步骤 #

• 用Query Monitor精准追踪：如果还能临时登录wp-admin，打开Query Monitor的「数据库查询」面板，按「调用次数」「耗时」排序，重点揪出重复执行、耗时久的查询，以及对应的调用栈（明确是WordPress核心哪个钩子/函数触发的）。若已无法登录，修改wp-config.php开启调试日志：

  define('WP_DEBUG', true);
  define('WP_DEBUG_LOG', true);
  define('WP_DEBUG_DISPLAY', false);
  

  日志会生成在wp-content/debug.log，里面会记录触发大量查询的具体代码位置。
• 开启MySQL慢查询日志：联系主机商开启慢查询日志（或自行在my.cnf/my.ini配置），设置long_query_time = 1（记录耗时1秒以上的查询），日志会直接显示哪些查询频繁执行、耗时过高，精准指向问题语句。
• 排查核心文件与数据库状态：即使已禁用插件和主题，也要确认WordPress核心文件是否被篡改，或数据库表是否损坏。可重新下载对应版本的WordPress核心包，覆盖wp-admin和wp-includes目录（先备份）；在phpMyAdmin中选择所有表，执行「优化表」「修复表」。
• 检查异常Cron任务：大量查询可能由异常Cron任务触发。用SQL临时禁用所有Cron任务，观察是否缓解：

  UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'cron';
  

  注意替换wp_为你的数据库表前缀，之后手动触发必要的Cron任务，逐个排查异常项。

二、实用SQL命令 #

• 查看当前用户资源使用情况：

  SHOW GLOBAL STATUS LIKE 'Com_update';
  SHOW VARIABLES LIKE 'max_updates_per_hour';
  

  前者查看当前已执行的更新次数，后者查看限制阈值，确认是否真的达到上限。
• 查询高频执行的SQL语句（需开启MySQL Performance Schema）：

  SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest ORDER BY COUNT_STAR DESC LIMIT 10;
  

  列出执行次数最多的10条SQL及总耗时，快速定位高频查询源。
• 检查数据库表索引：

  SHOW INDEX FROM wp_posts;
  SHOW INDEX FROM wp_postmeta;
  

  缺失索引会导致查询变慢，进而触发更多重试或批量查询，比如wp_postmeta的meta_key字段无索引时，极易引发大量慢查询。
• 实时查看数据库进程：

  SHOW PROCESSLIST;
  

  实时监控当前运行的数据库进程，排查是否有长时间阻塞的查询或重复执行的语句。

三、临时缓解措施 #

• 联系主机商临时提高max_updates_per_hour限制，争取足够排查时间。
• 禁用WordPress自动更新（若更新任务触发查询）：在wp-config.php添加：

  define('AUTOMATIC_UPDATER_DISABLED', true);
  

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