mysql - 需要添加什么索引才能使该查询正常工作？

Question

此查询会在我的慢查询日志中弹出:

SELECT
  COUNT(*)                 AS ordersCount,
  SUM(ItemsPrice + COALESCE(extrasPrice, 0.0)) AS totalValue,
  SUM(ItemsPrice)          AS totalValue,
  SUM(std_delivery_charge) AS totalStdDeliveryCharge,
  SUM(extra_delivery_charge) AS totalExtraDeliveryCharge,
  this_.type               AS y5_,
  this_.transmissionMethod AS y6_,
  this_.extra_delivery     AS y7_
FROM orders this_
WHERE this_.deliveryDate BETWEEN '2010-01-01 00:00:00' AND '2010-09-01 00:00:00'
    AND this_.status IN(1, 3, 2, 10, 4, 5, 11)
    AND this_.senderShop_id = 10017
GROUP BY this_.type, this_.transmissionMethod, this_.extra_delivery
ORDER BY this_.deliveryDate DESC;

该表是 InnoDB，大约有 880k 行，执行时间为 9-12 秒。我尝试添加以下索引 ALTER TABLE orders ADD INDEX _deliverydate_senderShopId_status ( deliveryDate , senderShop_id , status, type, transmissionMethod, extra_delivery);没有任何实际 yield 。欢迎任何帮助和/或建议

这是现在的查询执行计划:

id      select_type   table type    possible_keys   key                  key_len   ref    rows    filtered  Extra1       SIMPLE        this_ ref                     FKC3DF62E57562BA6F   8         const  139894  100.00    Using where; Using temporary; Using filesort

我从文本中取出了 possible_keys 值，因为我认为它列出了表中的所有索引。使用的 key (FKC3DF62E57562BA6F)看起来像

Keyname               Type   Unique  Packed  Field          Cardinality Collation   Null    CommentFKC3DF62E57562BA6F    BTREE  No      No      senderShop_id  4671        A

Answer 1

我会告诉您一件可以提高速度的事情。

数据中通常只有未知或不适用的行的 NULL 值。在我看来，既然你无论如何都将 NULL 视为 0，你应该考虑摆脱它们并确保所有 extrasPrice > 值现在为 0(之前为 NULL)，这样您就可以摆脱合并 的时间损失。

事实上，您可以更进一步，引入名为 totalPrice 的另一列，您可以使用插入/更新触发器将其设置为实际值 ItemsPrice + extrasPrice 或 (ItemsPrice + COALESCE(extrasPrice,0.0) 如果您仍需要 extrasPrice 为空性)。

然后，您可以简单地使用:

SELECT
    COUNT(*)          AS ordersCount,
    SUM(totalPrice)   AS totalValue,
    SUM(ItemsPrice)   AS totalValue2,
    :

(我不确定您是否应该有两个具有相同名称的输出列，或者这是否是一个拼写错误，这在最坏的情况下是一个错误，在最好的情况下，会令人困惑)。

这将计算成本转移到插入/更新时间而不是选择时间，并分摊所有选择的成本 - 大多数数据库表的读取次数远远多于写入次数。由于触发器保持了数据的一致性，性能应该会更好，但代价是一些存储需求。

但是，由于绝大多数数据库问题都是“如何获得更快的速度？”而不是“我怎样才能使用更少的磁盘？”，这通常是一个好主意。

另一个建议是在列上提供非复合索引，以最快地减少结果集(高基数)。换句话说，如果您的表中只存储了两周的数据(14 个不同的日期)，但存储了 400 个不同的商店，则您应该在 senderShop_id 上建立一个索引，并确保您的统计信息是最新的。

这应该会导致 DBMS 执行引擎使用该键缩减结果集，以便后续操作更快。

deliveryDate,senderShop_id,... 上的复合索引将无法使用 senderShop_id 来缩减结果，因为键排序将是 senderShop_id 内交货日期。