用于报告的 Wordpress/Woocommerce 自定义 SQL 查询疑难解答

Question

希望这是正确的论坛，我的问题似乎与堆栈交换社区重叠，所以这似乎是最好的。

我的 wordpress 网站上有一些针对我的 WooCommerce 订单的自定义报告。我有一个查询只是在本地冻结，这意味着在我的本地主机中我的 CPU 达到 100% 并且它永远不会完成，我不明白为什么。这里的重点是查询：

SELECT SUM(postmeta.meta_value)
FROM pca_postmeta AS postmeta
LEFT JOIN pca_woocommerce_order_items AS orders ON orders.order_id = postmeta.post_id
WHERE postmeta.meta_key = '_order_total'
AND orders.order_item_id IN (
    SELECT item_meta.order_item_id 
    FROM pca_woocommerce_order_itemmeta AS item_meta 
    LEFT JOIN pca_woocommerce_order_items AS orders ON item_meta.order_item_id = orders.order_item_id 
    LEFT JOIN pca_posts AS posts ON posts.ID = orders.order_id 
    WHERE item_meta.meta_value = '23563' 
    AND posts.post_status IN ('wc-processing','wc-completed') 
    GROUP BY orders.order_id
)

正如您希望看到的那样，这里的目标是获取来自此特定广告系列的所有订单的总和 (23563)。嵌套查询完全按预期工作，只返回一个 ID 列表，如下所示：

注意： 当它总共只返回 65 个时，如果 2.6289 秒很长，我有点好奇，尽管总共有 148220 个

问题是这个查询似乎不喜欢嵌套部分。有什么建议？考虑完全不同的方法？

附：我在其他时候也使用该嵌套查询在我的 php 报告类中按活动 ID 表示所有订单。但是对于我的问题，PHP 与它无关。

更新/跟进：

是否可以将其转换为如下所述的连接：Using a SELECT statement within a WHERE clause？我对我的 SQL 有点了解，所以不确定我会怎么做，但看起来很有希望

Answer 1

GROUP BY  orders.order_id

没有意义，因为您只选择了order_item_id。

pca_woocommerce_order_itemmeta 将受益于

INDEX(meta_value, order_item_id)

这个可能是一个等价的查询，但要避免IN(SELECT...):

SELECT  SUM(pm.meta_value)
    FROM  
      ( SELECT  im.order_item_id
            FROM  pca_woocommerce_order_itemmeta AS im
            LEFT JOIN  pca_woocommerce_order_items AS o
                             ON im.order_item_id = o.order_item_id
            LEFT JOIN  pca_posts AS posts ON posts.ID = o.order_id
            WHERE  im.meta_value = '23563'
              AND  posts.post_status IN ('wc-processing','wc-completed')
            GROUP BY  o.order_id 
      ) AS w
    JOIN  pca_woocommerce_order_items AS o ON w.order_item_id = o.order_item_id
    JOIN  pca_postmeta AS pm ON o.order_id = pm.post_id
    WHERE  pm.meta_key = '_order_total'

编辑

我所做的事情背后的一些原则。在这里，我猜测优化器将如何处理各种可能的查询公式。

• 我摆脱了LEFT -- 这可能改变了输出。但我需要避免 LEFT JOIN ( SELECT ... ) 无法优化。
• 通过在“表”列表中加入 一个 子查询，优化器将（几乎可以肯定）从子查询开始，并对其他表执行“嵌套循环连接”。 NLJ 是执行查询的常用方法。
• 这样的子选择没有索引，所以它需要在顺序中排在第一位，否则效率会很低。
• 如果没有子查询，优化器通常喜欢从 WHERE 子句中包含内容的任何表开始。
• 从子查询“表”开始的要求强于根据WHERE pm.meta_key = '_order_total' 选择表的愿望。
• 在子查询中，唯一的“=”测试 (WHERE im.meta_value = '23563) 为该组 JOIN 提供了可能的起点。这进一步增强了它不是LEFT JOIN 的“正确”。因此，我建议使用该索引。