为啥 MySQL 在这里并不总是使用索引合并？

Posted 2023-02-24

【中文标题】为啥 MySQL 在这里并不总是使用索引合并？

【英文标题】：Why does MySQL not always use index merge here?为什么 MySQL 在这里并不总是使用索引合并？

【发布时间】：2018-07-29 04:37:45

【问题描述】：

考虑这张表：

CREATE TABLE `Alarms` (
  `AlarmId` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `DeviceId` BINARY(16) NOT NULL,
  `Code` BIGINT(20) UNSIGNED NOT NULL,
  `Ended` TINYINT(1) NOT NULL DEFAULT '0',
  `NaturalEnd` TINYINT(1) NOT NULL DEFAULT '0',
  `Pinned` TINYINT(1) NOT NULL DEFAULT '0',
  `Acknowledged` TINYINT(1) NOT NULL DEFAULT '0',
  `StartedAt` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
  `EndedAt` TIMESTAMP NULL DEFAULT NULL,
  `MarkedForDeletion` TINYINT(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`AlarmId`),
  KEY `Key1` (`Ended`,`Acknowledged`),
  KEY `Key2` (`Pinned`),
  KEY `Key3` (`DeviceId`,`Pinned`),
  KEY `Key4` (`DeviceId`,`StartedAt`,`EndedAt`),
  KEY `Key5` (`DeviceId`,`Ended`,`EndedAt`),
  KEY `Key6` (`MarkedForDeletion`)
) ENGINE=INNODB;

并且，对于这个测试，像这样填充它：

-- Populate some dummy data; 500 alarms for each
-- of 1000 one-second periods
SET @testDevice = UNHEX('00030000000000000000000000000000');

DROP PROCEDURE IF EXISTS `injectAlarms`;
DELIMITER ;;
CREATE PROCEDURE injectAlarms()
BEGIN
    SET @fromdate  = '2018-02-18 00:00:00';
    SET @numdates  = 1000;
    SET @todate    = DATE_ADD(@fromdate, INTERVAL @numdates SECOND);

    -- Create table of alarm codes to join on
    DROP TABLE IF EXISTS `__codes`;
    CREATE TEMPORARY TABLE `__codes` (
        `Code` BIGINT NOT NULL PRIMARY KEY
    );

    SET @startcode = 0;
    SET @endcode   = 499;

    REPEAT
       INSERT INTO `__codes` VALUES(@startcode);
       SET @startcode = @startcode + 1;
    UNTIL @startcode > @endcode END REPEAT;

    -- Add an alarm for each code, for each second in range
    REPEAT
        INSERT INTO `Alarms`
            (`DeviceId`, `Code`, `Ended`, `NaturalEnd`, `Pinned`, `Acknowledged`, `StartedAt`, `EndedAt`)
            SELECT
                @testDevice,
                `Code`,
                TRUE, FALSE, FALSE, FALSE,
                @fromdate, @fromdate
            FROM `__codes`;

        SET @fromdate = DATE_ADD(@fromdate, INTERVAL 1 SECOND);
    UNTIL @fromdate > @todate END REPEAT;
END;;
DELIMITER ;

CALL injectAlarms();

现在，对于某些数据集，以下查询运行良好：

SELECT * FROM `Alarms`
WHERE
   ((`Alarms`.`Ended` = FALSE AND `Alarms`.`Acknowledged` = FALSE) OR `Alarms`.`Pinned` = TRUE) AND
   `MarkedForDeletion` = FALSE AND
   `DeviceId` = @testDevice
;

这是因为 MariaDB 足够聪明，可以使用索引合并，例如：

id    select_type    table    type         possible_keys                 
1     SIMPLE         Alarms   index_merge  Key1,Key2,Key3,Key4,Key5,Key6 

key             key_len  ref     rows     Extra
Key1,Key2,Key3  2,1,17   (NULL)  2        Using union(Key1,intersect(Key2,Key3)); Using where

但是，如果我使用上述过程填充的数据集，并稍微翻转查询（这是我需要的另一个视图，但在这种情况下会返回更多行）：

SELECT * FROM `Alarms`
WHERE
  ((`Alarms`.`Ended` = TRUE OR `Alarms`.`Acknowledged` = TRUE) AND `Alarms`.`Pinned` = FALSE) AND
   `MarkedForDeletion` = FALSE AND
   `DeviceId` = @testDevice
;

……它没有：

id    select_type    table    type   possible_keys
1     SIMPLE         Alarms   ref    Key1,Key2,Key3,Key4,Key5,Key6

key   key_len  ref     rows     Extra
Key2  1        const  144706    Using where

我希望索引合并更频繁地发生。事实上，鉴于ref=const，这个查询计划看起来并不太可怕……但是，查询需要将近一秒钟的时间才能运行。这本身并不是世界末日，但是当我尝试一个更奇特的查询时，我的设计的可扩展性很差，这需要 非常 很长时间：

-- Create a temporary table that we'll join against in a mo
DROP TABLE IF EXISTS `_ranges`;
CREATE TEMPORARY TABLE `_ranges` (
    `Start` TIMESTAMP NOT NULL DEFAULT 0,
    `End`   TIMESTAMP NOT NULL DEFAULT 0,
    PRIMARY KEY(`Start`, `End`)
);

-- Populate it (in reality this is performed by my application layer)
SET @endtime = 1518992216;
SET @starttime = @endtime - 86400;
SET @inter = 900;
DROP PROCEDURE IF EXISTS `populateRanges`;
DELIMITER ;;
CREATE PROCEDURE populateRanges()
BEGIN
REPEAT
    INSERT IGNORE INTO `_ranges` VALUES(FROM_UNIXTIME(@starttime),FROM_UNIXTIME(@starttime + @inter));
    SET @starttime = @starttime + @inter;
UNTIL @starttime > @endtime END REPEAT;
END;;
DELIMITER ;
CALL populateRanges();

-- Actual query
SELECT UNIX_TIMESTAMP(`_ranges`.`Start`) AS `Start_TS`,
COUNT(`Alarms`.`AlarmId`) AS `n`
FROM `_ranges`
LEFT JOIN `Alarms`
ON `Alarms`.`StartedAt` < `_ranges`.`End`
  AND (`Alarms`.`EndedAt` IS NULL OR `Alarms`.`EndedAt` >= `_ranges`.`Start`)

  AND ((`Alarms`.`EndedAt` IS NULL AND `Alarms`.`Acknowledged` = FALSE) OR `Alarms`.`Pinned` = TRUE)
-- Again, the above condition is sometimes replaced by:
-- AND ((`Alarms`.`EndedAt` IS NOT NULL OR `Alarms`.`Acknowledged` = TRUE) AND `Alarms`.`Pinned` = FALSE)

 AND `DeviceId` = @testDevice
 AND `MarkedForDeletion` = FALSE
 GROUP BY `_ranges`.`Start`

（此查询应该收集每个时间片的计数列表，每个计数指示有多少警报的 [StartedAt,EndedAt] 范围与该时间片相交。结果填充折线图。）

再一次，当我设计这些表并且其中没有多少行时，索引合并似乎使所有内容都运转起来。但现在不是这样：使用injectAlarms() 中给出的数据集，这需要 40 秒 才能完成！

我在添加 MarkedForDeletion 列并执行我的第一个大型数据集规模测试时注意到了这一点。这就是为什么我对索引的选择不会因为MarkedForDeletion 的存在而产生重大影响，尽管如果我从查询中删除AND MarkedForDeletion = FALSE，上述结果是相同的；但是，我保留了条件，因为最终我需要它在那里。

我尝试了一些USE INDEX/FORCE INDEX 组合，但结果似乎从未使用索引合并。

我可以定义哪些索引以使该表在给定情况下快速运行？或者我该如何重组我的查询以实现相同的目标？

（以上查询计划在 MariaDB 5.5.56/CentOS 7 上获得，但解决方案也必须在 mysql 5.1.73/CentOS 6 上运行。）

【问题讨论】：

刚刚在手册中发现了关于 AND/OR 缺陷的注释 - 打算尝试重新组织一下条件句

请记住，OR 基本上会扼杀任何优化的机会。同时，在 MarkedForDeletion 和 DeviceId 上建立一个复合索引（按任意顺序）应该会有所帮助。

@RickJames：我想我可以在由触发器填充的列中维护一些 OR 逻辑的结果......简化索引和查询......嗯。这种方法是典型的吗？

有一个值而不是NULL。示例EndedAt 可能是未来十年。这将是性能和清晰度之间的权衡。

@RickJames：嗯。我确实需要在其他地方进行结束/未结束的区分。我可以将其替换为与某个任意的未来日期进行比较，否则几乎可以回到我开始的地方。请注意，我确实有一个单独的 Ended 列。好的，值得研究使用一些巨大的 EndedAt 日期而不是 NULL 是否可以解决一些问题。会把它列入清单...

【参考方案1】：

哇！这是我见过的最复杂的“索引合并”。

通常（也许总是），您可以制作一个“复合”索引来替换索引合并相交，并表现更好。将 key2 从 (pinned) 更改为 (pinned, DeviceId)。这可能可以摆脱“相交”并加快速度。

一般来说，优化器只在绝望中使用索引合并。 （我认为这是标题问题的答案。）对查询或所涉及的值的任何细微更改，优化器将执行不合并索引的查询。

对 temp 表 __codes 的改进是构建一个包含大量值的永久表，然后在 Proc 中使用该表中的一系列值。如果您使用的是 MariaDB，则使用动态构建的“序列”表。例如，“表”seq_1_to_100实际上是一个包含数字 1..100 的一列的表。无需声明或填充它。

您可以通过计算 Code 的时间来摆脱另一个REPEAT 循环。

避免LOOPs 将是最大的性能优势。

完成所有这些，然后我可能会有其他提示。

【讨论】：

injectAlarms 中的所有内容都是为了展示，为问题的目的构建一个现实的（ish）样本数据集。你所说的索引合并和绝望肯定符合我的观察。将尝试更广泛的综合指数。

@LightnessRacesinOrbit - MariaDB 10.2 和 MySQL 5.7 可能在优化器中有所改进，您可以使用。请努力摆脱古董 5.1。

当然期待这一天。不过，这不在我的控制之下，除非我们开始发布从源代码构建的 MySQL，我并不热衷于开始这样做，而且我不相信我们的安全意识过度的客户无论如何都会接受脱离回购。

@LightnessRacesinOrbit - 用我的建议尽你所能，然后回来寻求更多建议/滥用。

提醒您的客户，自从 4 年多前 EOL（生命周期结束）以来，安全修复程序尚未向后移植到 5.1：December 31, 2013。