MySQL索引没有在大型数据库中使用

时间:2018-05-14 17:08:46

标签: mysql indexing explain

我在一个大表(大约3700万行)上有一个非常简单的查询。这个查询需要10分钟才能运行,并且应该很快,因为索引是正确构建的(我认为)。我不明白为什么这个查询需要这么长时间。我希望有人可以指导我朝着正确的方向前进:

查询:

select type_id, sub_type_id, max(settlement_date_time) as max_dt 
from transaction_history group by type_id, sub_type_id

创建声明:

 CREATE TABLE `transaction_history` (
 `transaction_history_id` int(11) NOT NULL AUTO_INCREMENT,
 `type_id` int(11) NOT NULL,
 `sub_type_id` int(11) DEFAULT NULL,     
 `settlement_date_time` datetime DEFAULT NULL,
 PRIMARY KEY (`transaction_history_id`),     
 KEY `sub_type_id_idx` (`sub_type_id_id`),
 KEY `settlement_date` (`settlement_date_time`),
 KEY `type_sub_type` (`type_id`,`sub_type_id`)
) ENGINE=InnoDB AUTO_INCREMENT=36832823 DEFAULT CHARSET=latin1;

解释结果:

id -> 1
select_type -> SIMPLE
table -> transaction_history
type -> index
possible_keys -> NULL
key -> type_sub_type
key_len -> 9
ref -> NULL
rows -> 37025337
filtered -> 100.00
Extra -> 

为什么可能的键为NULL?它说它正在使用索引,但它似乎不是。为什么ref NULL?如何使此查询更有效?索引有问题吗?我是否必须更改MySQL配置文件的任何值?

谢谢

1 个答案:

答案 0 :(得分:0)

(向已经提供必要INDEX的两位评论者道歉;我会尽力说出足以证明给出“答案”的理由。)

使用'复合'(和'覆盖')索引:

INDEX(type_id, sub_type_id, settlement_date_time)

没有WHERE,因此无需担心此类列。首先按照GROUP BY中列出的顺序排列,然后是另一列。优化器可能会非常有效地跳过索引。

为什么NULL?那么2列索引是没用的。一般来说,如果需要查看超过20%的表,最好只扫描表而不是在索引BTree和数据BTree之间跳转。

更多提示:http://mysql.rjweb.org/doc.php/index_cookbook_mysql