gpt4 book ai didi

mysql - 为什么主键比索引快?

转载 作者:行者123 更新时间:2023-11-29 00:07:39 24 4
gpt4 key购买 nike

我有一个 MySQL 5.5 表,如下所示;

CREATE TABLE `date_test` (
`id` int(11) NOT NULL DEFAULT '0',
`report_date` datetime NOT NULL,
`module_id` int(11) NOT NULL,
`country_id` int(11) NOT NULL,
`clicks` int(11) DEFAULT '0'
PRIMARY KEY (`id`,`report_date`,`module_id`,`country_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

只有一个PK,没有Index。运行一个简单的 SELECT 查询;

select count(*) from date_test
where report_date between'2014-09-01' and '2014-09-15'

这需要 1.1 秒,返回 809,349 条记录。

现在,我在 report_date 上添加了一个索引,以尝试加快速度;

ALTER TABLE `date_test`
ADD INDEX `report_date` (`report_date` ASC);

我的 select count(*) 查询现在需要 2.6 秒 来运行。我的问题;将此字段添加为索引对查询性能有何影响?

添加解释;

With Index and PK (2.6 seconds) 
id 1
select_type SIMPLE
table date_test
type range
possible_keys report_date
key report_date
key_len 8
ref
rows 792170
Extra Using where; Using index

With PK only, no Index (1.1 seconds)
id 1
select_type SIMPLE
table date_test
type index
possible_keys
key PRIMARY
key_len 1048
ref
rows 1584341
Extra Using where; Using index

With no Index or PK (1.4 seconds)
id 1
select_type SIMPLE
table date_test
type ALL
possible_keys
key
key_len
ref
rows 1652883
Extra Using where

最佳答案

查看 EXPLAIN <YOUR_QUERY> 的结果.我的猜测是(没有足够的信息可以确定)MySQL 现在正在使用索引并且错误地猜测使用索引会更快。

如果索引覆盖的行数比简单地进行表扫描会更快。索引会在查询时增加一些开销,所以如果 between覆盖表中超过 80%(完全任意,但你明白)的行,表扫描可以更快。

查看此查询的输出以获得一个想法:

SELECT report_date between '2014-09-01' and '2014-09-15', COUNT(*) FROM date_Test
GROUP BY report_date between '2014-09-01' and '2014-09-15'

关于mysql - 为什么主键比索引快?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26760469/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com