WooCommerce站点繁忙时段CPU跑满100%慢查询溯源及优化求助

第一步：定位慢查询触发来源 #

• 短时间开启MySQL全量日志（general log），仅在业务低峰或即将进入高峰时开启1-5分钟，日志中会记录每条查询对应的发起进程信息，结合服务器进程列表可追溯到对应的PHP脚本路径，确认是主题、插件还是后台定时任务触发。
• 全局扫描站点wp-content目录下的代码，以查询中涉及的特征逻辑为搜索关键词：比如UNION ALL、对应实际的meta_key（你示例中的S为脱敏占位符，替换为实际值搜索）、关联wp_termmeta和wp_postmeta的筛选逻辑，10分钟内即可定位到具体的代码片段。
• 排查WP Cron触发逻辑：Query Monitor默认不会捕获后台Cron任务触发的查询，你可以先将WP原生Cron关闭，替换为Linux系统级Cron定时执行，避免用户访问时随机触发高负载查询。

第二步：慢查询本身优化 #

你现有的查询存在大量冗余逻辑和低效率写法，即使索引齐全也会导致高耗时，调整方向如下：

• 替换所有NOT IN子查询为NOT EXISTS或者LEFT JOIN + IS NULL写法：MySQL对NOT IN的子查询优化很差，尤其子查询返回结果集较大时会大幅提升扫描行数，替换后性能可提升3-10倍。
• 合并重复逻辑：查询中SELECT post_id FROM wp_postmeta WHERE meta_key = 'S'、关联wp_termmeta和wp_term_relationships的逻辑都重复出现了2次，可以提前用CTE或者临时表提取公共逻辑，避免重复执行。
• 去掉冗余去重操作：你用了UNION ALL（不去重）之后外层又加了SELECT DISTINCT，同时子查询内部也加了多余的DISTINCT，统一调整为用UNION（自带去重）即可，减少多余的排序去重开销。
• 补充覆盖索引：将现有单字段索引替换为联合覆盖索引，避免回表查询：
  • wp_postmeta加(meta_key, post_id, meta_value)联合索引
  • wp_termmeta加(meta_key, term_id, meta_value)联合索引
  • wp_term_relationships加(term_taxonomy_id, object_id)联合索引
    调整后该查询的平均执行时间可从20s降到1s以内，锁等待时间也会随之消失。

第三步：临时兜底方案 #

在定位到根源问题前，可先通过以下方案避免CPU打满的故障：

• 安装WordPress Redis对象缓存插件，将这类筛选查询的结果缓存1-2小时（根据业务内容更新频率调整），避免每次请求都重复执行SQL。
• 调整MySQL配置：将tmp_table_size和max_heap_table_size统一调整为256M，避免查询生成磁盘临时表，提升执行效率。
• 限制慢查询并发：可以通过MySQL的并发控制插件，或者在WP层面加互斥锁，避免同一个慢查询同时被多次触发，放大锁竞争问题。

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