gpt4 book ai didi

MySQL 5.1 在存在索引时使用文件排序事件

转载 作者:可可西里 更新时间:2023-11-01 06:49:16 26 4
gpt4 key购买 nike

可能我遗漏了一些愚蠢的东西...显然 MySQL 5.1 会继续执行文件排序,即使存在与 ORDER BY 子句中的列完全匹配的索引也是如此。在这里发布,我过度简化了数据模型,但问题仍然存在:

表定义:

CREATE TABLE `event` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`owner_id` int(11) DEFAULT NULL,
`date_created` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `owner_id` (`owner_id`),
KEY `date_created` (`date_created`),
CONSTRAINT `event_ibfk_1` FOREIGN KEY (`owner_id`) REFERENCES `user_profile` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;

我的问题是一个简单的 SELECT 事件显示“使用文件排序”:

explain select * from event order by date_created desc;

查询结果说明:

id  select_type table   type    possible_keys   key key_len ref rows    Extra   
1 SIMPLE event ALL NULL NULL NULL NULL 6 Using filesort

有没有办法让这种类型的查询使用索引而不是进行文件排序?

在此先感谢大家。

最佳答案

由于您的 CREATE TABLE 语句表明您的行数少于 10 (AUTO_INCREMENT=7) 并且在我的安装中使用 FORCE INDEX 将让 MySQL 使用索引,我猜优化器认为表扫描比索引扫描更快(随机 I/O 更少)(因为您选择的是所有列,而不仅仅是 date_created)。以下内容证实了这一点:

mysql> explain select date_created from event order by date_created;
+----+-------------+-------+-------+---------------+--------------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+--------------+---------+------+------+-------------+
| 1 | SIMPLE | event | index | NULL | date_created | 9 | NULL | 1 | Using index |
+----+-------------+-------+-------+---------------+--------------+---------+------+------+-------------+
1 row in set (0.00 sec)

在上述情况下,索引扫描速度更快,因为只需要返回索引列。

MySQL 文档有一些使用索引被认为较慢的情况:http://dev.mysql.com/doc/refman/5.1/en/how-to-avoid-table-scan.html

关于MySQL 5.1 在存在索引时使用文件排序事件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6114880/

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