当表很大时，mysql 查询不使用索引

Question

我有一张 table :

CREATE TABLE `p` (  
`id` bigint(20) unsigned NOT NULL,  
`rtime` datetime NOT NULL,  
`d` int(10) NOT NULL,  
`n` int(10) NOT NULL,  
PRIMARY KEY (`rtime`,`id`,`d`) USING BTREE  
) ENGINE=MyISAM DEFAULT CHARSET=latin1;  

我有一个问题:

select id, d, sum(n) from p where  rtime between '2012-08-25' and date(now()) group by id, d;

我正在一个小表(2 条记录)上对此查询运行解释，它告诉我它将使用我的 PK:

id  | select_type  | table | type   | possible_keys key  | key     | key_len | ref  | rows | Extra
1   | SIMPLE       | p     | range  | PRIMARY            | PRIMARY | 8       | NULL | 1    | Using where; Using temporary; Using filesort

但是当我在同一个表上使用相同的查询时——只是这次它很大(3.5 亿条记录)——它更喜欢遍历所有记录并忽略我的键

id  | select_type  | table  | type | possible_keys  | key  | key_len | ref  | rows      | Extra
1   | SIMPLE       | p      | ALL  | PRIMARY        | NULL | NULL    | NULL | 355465280 | Using where; Using temporary; Using filesort

显然，这非常慢.. 谁能帮忙？

编辑:这个简单的查询也花费了大量时间:

select count(*) from propagation_delay where  rtime > '2012-08-28';

Answer 1

您的查询:

...WHERE rtime between '2012-08-25' and date(now()) group by id, d;

使用 rtime，并按 id 和 d 分组。至少您应该按 rtime 建立索引。您可能还想尝试按此顺序按 rtime, id, d, n 建立索引，但是当您这样做时，您会发现索引将包含与表或多或少相同的数据。

优化器可能会进行一些计算并得出结论，使用索引并不值得。

我会在 rtime 上单独留下一个索引。真正的关键在于有多少记录与 WHERE 匹配 - 如果只有几条记录，则可以方便地读取索引并在表中跳来跳去。如果它们有多个，也许最好按顺序扫描整个表，从而节省来回读取。

the query is getting a big chunk out of those 350 mil - i'd say a few millions

好吧，那么很可能从索引中快速抽取五千万条记录，然后在主表中来回穿梭恢复那五千万条记录的累计成本，可能比开启的成本还多主表，并沿途搜索所有 350M 记录分组和汇总。

在这种情况下，如果您总是(或大部分)在 rtime 上运行聚合查询，并且该表是一个累积(历史)表，并且每对 (id, d) 每天会看到几十个条目，您可以考虑创建一个按日期聚合 辅助表。即，在(比如说)午夜，您运行查询并

INSERT INTO aggregate_table
    SELECT DATE(@yesterday) AS rtime, id, d, sum(n) AS n
    FROM main_table WHERE DATE(rtime) = @yesterday GROUP BY id, d;

aggregate_table 中的数据只有每对 (id, d) 有一个条目，保存当天 n 的总和；该表按比例变小，查询速度更快。这假设您的 (id, d) 数量相对较少，并且它们中的每一个每天都会在主表中生成大量行。

如果每对夫妇每分钟记录一次，聚合应该可以将速度提高三个数量级以上(相反，如果您每天两次获取大量不同的传感器，则好处可以忽略不计)。