左连接比内连接运行得快得多

Question

我一直在尝试优化我已经成功完成的查询的性能。使用左连接的时间从 36.7 秒缩短到了 3.3 秒，但我不太明白为什么左连接与普通连接相比性能有如此大的提升。

两个查询买回的结果集是相同的。

这里是带有 EXPLAIN 的查询...

正常加入：36.7 秒

SELECT t1.entityId, SUM(t2.gbp) AS amount
FROM transactionsV2 t1
JOIN
(
    SELECT
    t.uniqueId,
    ROUND((CASE WHEN t.currency != "GBP" THEN t.amount/er.exchange_rate ELSE t.amount END), 2) AS gbp
    FROM transactionsV2 t
    JOIN total_control.exchange_rates er 
    ON t.currency = er.currency
    ) t2
ON t1.uniqueId = t2.uniqueId
WHERE t1.paymentType IN ("DB", "3D")
AND t1.processing_time >= '2019-04-01 00:00:00'
AND t1.processing_time <= '2019-04-20 23:59:59'
AND t1.status = 1
GROUP BY t1.entityId

左加入：3.3 秒

SELECT t1.entityId, SUM(t2.gbp) AS amount
FROM transactionsV2 t1
LEFT JOIN
(
    SELECT
    t.uniqueId,
    ROUND((CASE WHEN t.currency != "GBP" THEN t.amount/er.exchange_rate ELSE t.amount END), 2) AS gbp
    FROM transactionsV2 t
    JOIN total_control.exchange_rates er 
    ON t.currency = er.currency
    ) t2
ON t1.uniqueId = t2.uniqueId
WHERE t1.paymentType IN ("DB", "3D")
AND t1.processing_time >= '2019-04-01 00:00:00'
AND t1.processing_time <= '2019-04-20 23:59:59'
AND t1.status = 1
GROUP BY t1.entityId

Answer 1

你能把它表达为一个相关的子查询吗？

SELECT t.entityId,
       (SELECT  SUM(CASE WHEN t2.currency <> 'GBP' THEN t2.amount/er.exchange_rate ELSE t.amount END)j
SUM(t2.gbp) AS amount
        FROM transactionsV2 t2 JOIN
             total_control.exchange_rates er 
             ON t.currency = er.currency
        WHERE t2.uniqueid = t.uniqueid
FROM transactionsV2 t
WHERE t.paymentType IN ('DB', '3D') AND
      t.processing_time >= '2019-04-01' AND
      t.processing_time < '2019-04-21' AND
      t.status = 1;

如果是这样，您可以向基础表添加索引以提高性能。但是，我怀疑事务表确实是一个视图。

Answer 2

虽然我无法解释为什么它正在做它正在做的事情......我不知道为什么当所有事务都来自 TransactionsV2 表时你是自加入的。内部左连接正在拉动所有加入汇率的交易，但没有应用任何地方，因此拉动了所有交易。然后在特定日期加入外部实例。

据我所见，您的 TransactionV2 表的结构类似于...

UniqueID auto-increment
EntityID (such as multiple transactions for this one person/company/entity)
Amount (based on relation to exchange rate and transaction amount)

因此，您将外部的每个唯一 ID 转换为内部的唯一 ID 一旦汇率计算完成，但最终仍按实体分组...... 我会尝试类似的东西。

SELECT
        t1.EntityID,
        SUM( ROUND(CASE WHEN t1.currency != "GBP" 
                        THEN t.amount/er.exchange_rate 
                        ELSE t.amount END, 2) ) Amount
    from
        TransactionsV2 t1
            LEFT JOIN total_control.exchange_rates er 
                ON t1.currency = er.currency
    WHERE 
            t1.paymentType IN ("DB", "3D")
        AND t1.processing_time >= '2019-04-01 00:00:00'
        AND t1.processing_time <= '2019-04-20 23:59:59'
        AND t1.status = 1
    GROUP BY 
        t1.entityId

它会检查一次记录，并且仅针对标准。如果没有记录，我将汇率的联接更改为 LEFT-JOIN - 因为我不知道可能（或不）匹配的确切条件。也许这就是你的 != "GBP" 值/何时。

为了帮助确保一些优化和交易量，我将在您的交易表上建立一个复合索引

( Status, Processing_Time, PaymentType, EntityID )

Answer 3

我猜性能是不同的，因为INNER JOIN (JOIN) 和LEFT JOIN 使用的表连接方式及其对索引的影响不同。

首先查看EXPLAIN 中的顺序。 您可以看到LEFT JOIN 将以固定顺序（从左到右）连接表。 INNER JOIN - 优化器将为您构建连接顺序（首先是小表）。 对于这两种情况，key 表 t1（在 EXPLAIN 列表中）是不同的。

当连接顺序不同时，是否应用索引（正确索引）总是取决于表的结构。例如，它甚至可以依赖于不同的表排序规则。

这样看，希望会有结果。