为什么索引会使查询变得非常慢？

Question

有一天，我在 SO 上回答了 question（被接受为正确），但答案让我非常怀疑。
很快，用户就有了一个包含以下字段的表：

id INT PRIMARY KEY
dt DATETIME (with an INDEX)
lt DOUBLE

查询SELECT DATE(dt),AVG(lt) FROM table GROUP BY DATE(dt) 真的很慢。 我们告诉他（部分）问题在于使用 DATE(dt) 作为字段和分组，但 db 位于生产服务器上，无法拆分该字段。
因此（使用触发器）插入了另一个字段da DATE (with an INDEX)，自动填充了 DATE(dt)。查询 SELECT da,AVG(lt) FROM table GROUP BY da 稍微快一点，但大约有 800 万条记录，它花了大约 60 秒！！！
我在我的电脑上试过，最后我发现，删除字段 da 查询上的索引只需要 7 秒，而删除索引后使用 DATE(dt) 需要 13 秒。 我一直认为用于分组的列上的索引可以真正加快查询速度，而不是相反（慢 8 倍！！！）。
为什么？是什么原因？
非常感谢。

Answer 1

因为您仍然需要从索引 + 数据文件中读取所有数据。由于您没有使用任何 where 条件 - 您将始终拥有查询计划，该计划逐行访问所有数据，您对此无能为力。

如果性能对此查询很重要并且经常执行 - 我建议将结果缓存到某个临时表中并每小时（每天等）更新一次。

为什么变慢：因为在索引中数据已经排序，当mysql计算查询执行的成本时，它认为使用已经排序的数据会更好，然后对它进行分组，然后计算聚合。但在这种情况下并非如此。

Answer 2

我认为这是因为这个或类似的 MySQL 错误：Index degrades sort performance and optimizer does not honor IGNORE INDEX

Answer 3

我记得这个问题，因为我正要回答它，但被别的东西分心了。问题是他的表设计没有利用聚集主键索引。

我会重新设计表，创建一个复合聚簇主键，其中日期作为索引的前导部分。 sm_id 字段仍然只是一个连续的 unsigned int 以保证唯一性。

drop table if exists speed_monitor;
create table speed_monitor 
(
created_date date not null,
sm_id int unsigned not null,
load_time_secs double(10,4) not null default 0,
primary key (created_date, sm_id)
)
engine=innodb;

+------+----------+
| year | count(*) |
+------+----------+
| 2009 | 22723200 | 22 million
| 2010 | 31536000 | 31 million
| 2011 |  5740800 |  5 million
+------+----------+

select 
 created_date, 
 count(*) as counter,
 avg(load_time_secs) as avg_load_time_secs
from
 speed_monitor
where
 created_date between '2010-01-01' and '2010-12-31'
group by
 created_date
order by
 created_date
limit 7;

-- cold runtime

+--------------+---------+--------------------+
| created_date | counter | avg_load_time_secs |
+--------------+---------+--------------------+
| 2010-01-01   |   86400 |         1.66546802 |
| 2010-01-02   |   86400 |         1.66662466 |
| 2010-01-03   |   86400 |         1.66081309 |
| 2010-01-04   |   86400 |         1.66582251 |
| 2010-01-05   |   86400 |         1.66522316 |
| 2010-01-06   |   86400 |         1.66859480 |
| 2010-01-07   |   86400 |         1.67320440 |
+--------------+---------+--------------------+
7 rows in set (0.23 sec)