MySQL：在进行 ID 查找时如何避免所有分区扫描（基于年份）？

Question

如果我有一个按年份分区的表；当我必须通过其 ID 查找行并且无法在查找查询中使用分区修剪时，如何避免扫描所有分区？

CREATE TABLE part_table (
    id bigint NOT NULL auto_increment,
    moment datetime NOT NULL,

    KEY (id),
    KEY (moment)
)-- partitioning information (in years)
    PARTITION BY RANGE( YEAR(moment) ) (
    PARTITION p2020 VALUES LESS THAN (2021),
    PARTITION p2021 VALUES LESS THAN (2022),
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p2025 VALUES LESS THAN (2026),
    PARTITION pFuture VALUES LESS THAN (maxvalue) )
;

例如查询查询：

SELECT * FROM part_table WHERE ID = <nr>

Answer 1

• 您不想要PRIMARY KEY(id, moment) 或PRIMARY KEY(moment, id) 而不是INDEX(id)？
• 索引被分区。每个分区本质上是一个“表”。它有一个用于数据和 PK 的 BTree，以及一个用于每个二级索引的 BTree。
• 所以，要找到id=123 需要检查每个分区中的INDEX(id)。这就是为什么 PARTITIONed 表有时慢比等效的非分区表的原因之一。
• 预先创建未来的分区（除了一个）是低效的。

向我们展示您的主要疑问。我可能会解释为什么不应该对表进行分区。我在您的定义中看到了两个可能的好处：

• 删除“旧”数据比 DELETEing 它快得多。
• `WHERE something-else AND moment between ..

一些案例

对于本次讨论，我假设以某种方式（BY RANGE(TO_DAYS(moment)) 或 BY ... (YEAR(moment)) 等）按日期时间进行分区。

WHERE id BETWEEN 111 and 222

分区可能会带来些许伤害，因为无论有哪些索引可用，查询都必须查看每个分区。

WHERE id BETWEEN 111 and 222
  AND moment > NOW() - INTERVAL 1 MONTH
with some index starting with `id`

这是分区“修剪”有益的情况。它将查看一个或两个分区（取决于查询是否在一月份运行）。然后它会在某种程度上有效地使用索引来查找id。

现在让我们讨论一下索引以id 开头的两种风格（并假设上面的WHERE 子句之一：

PRIMARY KEY(id, moment)

PK 与数据“聚集”在一起。也就是说，数据首先按id 排序，然后是moment。因此id BETWEEN... 将在 BTree 中连续找到行——这是最有效的。 AND moment... 用于过滤一些行。

INDEX(id)

不是“集群”。它是二级索引。二级索引需要两个步骤。 (1) 在二级BTree中搜索id，但不通过moment过滤； (2) 使用为您提供的人工PK进入数据BTree； (3) 现在可以通过moment 进行过滤。更多的步骤，更多的阅读块等等。

DROP PARTITION p2020

id much 比 `DELETE .. WHERE moment

更多

查看所有主要查询很重要。 X=constant 与 X BETWEEN... 可以在优化方面产生很大的不同；请提供适合您应用的具体示例。

此外，有时“覆盖”索引可以弥补其他效率低下的索引。因此，这些示例需要显示重要查询中的所有列。以及它们是什么数据类型。

在没有这些细节的情况下，我将做出以下广泛的陈述（可能会因细节而无效）：

• 如果 WHERE 仅引用一列，则 PARTITIONing 可能永远不会有用。
• 如果WHERE 有一个= 测试和一个“范围”测试，则可能有一个复合索引比分区更有效。
• 当有两个范围测试时，分区可能会发光，但前提是可以应用“修剪”。 （修剪有很多限制。）
• 对于 2 个范围，未修剪的范围应位于 PRIMARY KEY 的开头。
• 当使用修剪但WHERE 的其余部分不能使用某些索引时，这意味着扫描分区。如果只有几个分区，那可能是一次大扫描。
• 不要预先构建多个分区。在不剪枝的情况下，打开所有分区却发现有些是空的，代价有点高。