MySQL聚类与非聚类索引性能

Question

我正在对MySQL群集与非聚类索引进行几个测试，其中我有一个表100GB_Table包含〜6000万行的：

100gb_table schema:
CREATE TABLE 100gb_table (
    id int PRIMARY KEY NOT NULL AUTO_INCREMENT,
    c1 int,
    c2 text,
    c3 text,
    c4 blob NOT NULL,
    c5 text,
    c6 text,
    ts timestamp NOT NULL default(CURRENT_TIMESTAMP)
);

我正在执行一个查询，该查询只读取群集索引：

SELECT id FROM 100gb_table ORDER BY id;

i'' m看到这个查询完成了几乎 〜55分钟，这很慢。我通过在主键列的顶部添加另一个索引来修改表，并运行以下查询，该查询迫使要使用的非群集索引：

SELECT id FROM 100gb_table USE INDEX (non_clustered_key) ORDER BY id;

在＆lt; 10分钟中完成，比阅读快得多。与群集索引。为什么这两者之间存在如此巨大的差异？我的理解是，这两个索引都将索引列的值存储在树结构中，除了群集索引包含叶子节点中的表数据，因此我希望两个查询都表现出类似的性能。 Blob列可能会扭曲聚类索引结构吗？

Answer 1

答案是如何列出数据。

主键与数据一起“聚集”；也就是说，数据由B+树结构中的PK订购。要读取所有ids，必须读取整个btree。

任何次级索引也都在B+树结构中，但它包含（1）索引的列，以及（2）PK中的任何其他列。

在您的示例中（大概有很多[大概]笨重的列），数据btree比辅助索引大得多（仅ID）。任何一个测试都可能需要从磁盘中读取所有相关块。

旁注...这还不如可能。一排的大小约为8KB。 文本和blob列（当简短）中包含在该8KB中。但是，当一个人笨重时，它会放在另一个地方，留下文本/斑点的“指针”。因此，数据btree的主要部分比直接包含所有文本/斑点数据的情况小。

由于从tbl中选择ID是一个不必要的查询，因此InnoDB的设计不必担心您发现的效率低下。

通过或在其中等上订购订单，并且可以进行许多不同的优化。您甚至可能会发现索引（C1）将使您的查询在不超过10分钟内运行。 （我想我已经为您提供了“为什么”的所有线索。）

另外，如果您从TBL 中完成了选择 *，则可能需要超过55分钟。这是因为有额外的[随机]获取以获取“外记录”存储中的文本/斑点。从网络时间到铲除更多数据。