mysql - MySQL SELECT 的速度(在变化很小的列上索引是否值得)？

Question

我已经对这个主题进行了大量搜索/阅读，但我仍然找不到解决方案。

我的表包含数万或数十万行，总计大约 300GB 的数据。我需要选择的列包含大量 HTML，这可能是问题的一部分。我正在使用压缩。该查询包含两个 WHERE 子句:

 SELECT id, olr_id, COMPRESS(source_html) 
 FROM buildings 
 WHERE scrape_status=1 
 AND parse_status=0 LIMIT 1;

正如人们所料，id 是主键。此外，olr_id 是唯一索引。这个查询需要大约 160-300 秒才能返回结果，这是完全不可行的。奇怪的是(至少对我来说)，删除 parse_status 的 WHERE 子句会导致查询在 2-3 秒内完成。起初，我认为这可能是因为它太具体了，所以我什至尝试删除 scrape_status 并只运行 parse_status WHERE 子句，但显然是这个特定子句导致了执行时间疯狂增加。

问题是，我不知道对这些列建立索引是否有任何好处(scrape_status 和 parse_status)，因为它们的值范围是 0-2 。我想这是我的主要问题——对值差异如此小的列进行索引是否有帮助？我曾经在某处读到过，索引对于变化很大的列来说确实是最好的，但正如我所说，我不知道该怎么做，而且 160-300 秒对于数十万条记录来说是完全不合理的。

任何意见都将不胜感激。如果您需要其他意见来帮助我，我很乐意提供。请注意，这些是三个查询中每个查询的 EXPLAIN 结果:

id: 1
select_type: SIMPLE
table: building
type: ALL
possible_keys: null
key: null
key_len: null
ref: null
rows: 58664
Extra: Using where

感谢您花时间阅读并提供任何帮助。

Answer 1

在 WHERE 子句中创建两列的复合索引:

CREATE INDEX ix_sp ON buildings (scrape_status, parse_status);

虽然它们本身不会对表进行太多分区，但组合起来可能会造成太大影响。

也请尝试以下操作:

SELECT b1.id, olr_id, COMPRESS(source_html)
from buildings b1
JOIN (SELECT id
      FROM buildings 
      WHERE scrape_status=1 
      AND parse_status=0
      LIMIT 1) b2
USING (id)

您的原始查询可能会压缩所有匹配的行，即使其中大部分都被 LIMIT 子句丢弃。此版本仅压缩选定的一个行。