在有序范围查询上优化mysql索引

我正在寻找一些攻击性的mysql查询的帮助，这些查询目前正在我的服务器上运行。我的目标是展示最昂贵的易趣物品，结束时间不到一个月

我正在使用MySQL 5.1

我的查询如下（“易趣商品”约有350000行）：

收益率：

*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: ebay_items
type: range
possible_keys: endtime
key: endtime
key_len: 9
ref: NULL
rows: 71760
Extra: Using where; Using filesort
1 row in set (0.00 sec)

此查询导致使用71760行的昂贵的“文件排序”

show indexes on ebay_items;

收益率（我只包括有问题的指数“endtime”）：

仅使用复合结束时间索引（结束时间，价格）的“结束时间”键。据我所知，MySQL在处理范围查询和'ORDERBY'子句时不会有效地使用复合索引

有没有人找到解决这个问题的好方法？我主要希望在DB级别解决它（通过更智能地使用索引或模式更改），但我愿意接受建议

我可以避免范围查询的一种方法是让后台任务每X小时循环一次，并在ebay_项目上将枚举类型字段标记为“<1天”、“小于1周”、“小于1个月”等。我希望以更简洁的方式解决此问题

有没有办法使用ORDERBY子句高效地执行MySQL范围查询

非常感谢你的帮助

编辑：科哈尼·罗伯特（Kohányi Róbert）说得很好，我应该澄清我在查询中遇到的确切问题。查询将导致磁盘I/O在其持续时间内被锁定。如果其中几个查询同时运行，则会备份进程并锁定机器。我的假设是文件排序正在吞噬I/O

我还应该提到，该表正在使用MyISAM引擎。使用InnoDB引擎是否会提高性能并降低I/O密集度？再次感谢。

引言 我喜欢你的问题，所以我玩了一点MySQL，并试图找到问题的根源。为此，我创建了一些测试

资料 我已经使用一个名为的工具生成了100000行样本数据（我认为文档有点过时，但它可以工作）。我传递给gendata.pl的配置文件如下所示

$tables={
行=>[100000]，
名称=>['ebay_items']，
引擎=>['MyISAM']，
pk=>['int auto_increment']
};
$fields={
类型=>['datetime'，'int']，
索引=>[undf]
};
$data={
数字=>[
“tinyint unsigned”，
'smallint unsigned'，
'smallint unsigned'，
“mediumint未签名”
],
时间=>['datetime']
}; 

我已经运行了两个独立的批测试：一个使用MyISAM表，另一个使用InnoDB。（因此，在上面的代码片段中，基本上是用InnoDB替换MyISAM。）

桌子 该工具创建一个表，其中的列被称为

pk

、

col\u datetime

和

col\u int

。我已重命名它们以匹配表的列。结果表就在下面

+---------+----------+------+-----+---------+----------------+
|字段|类型|空|键|默认|额外|
+---------+----------+------+-----+---------+----------------+
|endtime | datetime | YES | MUL | NULL ||
|id | int（11）| NO | PRI | NULL |自动增量|
|价格|整数（11）|是| MUL |空||
+---------+----------+------+-----+---------+----------------+

指数 该工具不创建索引，因为我希望它能够手动创建索引

在“易趣”项目上创建索引“endtime”（endtime，price）；
在“易趣物品”上创建索引“价格”（价格，结束时间）；
在“易趣物品”（endtime）上创建索引“仅限endtime”；
在“易趣物品”（价格）上创建“仅价格”索引；

查询 我使用的查询

选择“易趣物品”。*
从“易趣物品”开始
力量指数（`endtime | price | endtime | only | price | `）
其中（`endtime`>'2009-01-01'-间隔1个月）
按“价格”说明订购

（四个不同的查询使用其中一个索引。我使用了

2009-01-01

而不是

NOW（）

，因为该工具似乎在2009年左右生成日期。）

说明 下面是MyISAM（顶部）和InnoDB（底部）表上每个索引的上述查询的

EXPLAIN

输出

结束时间

id:1
选择类型：简单
表：易趣商品
类型：范围
可能的_键：endtime
关键字：结束时间
重点：9
ref:NULL
行数：25261
额外：在何处使用；使用文件排序
身份证号码：1
选择类型：简单
表：易趣商品
类型：范围
可能的_键：endtime
关键字：结束时间
重点：9
ref:NULL
行数：21026
额外：在何处使用；使用指数；使用文件排序

价格

id:1
选择类型：简单
表：易趣商品
类型：索引
可能的_键：NULL
关键词：价格
重点：14
ref:NULL
行数：100000
额外：使用where
身份证号码：1
选择类型：简单
表：易趣商品
类型：索引
可能的_键：NULL
关键词：价格
重点：14
ref:NULL
行数：100226
额外：在何处使用；使用索引

仅限结束时间

id:1
选择类型：简单
表：易趣商品
类型：范围
可能的_键：仅限endtime_
关键字：仅限endtime_
重点：9
ref:NULL
行数：11666
额外：在何处使用；使用文件排序
身份证号码：1
选择类型：简单
表：易趣商品
类型：范围
可能的_键：仅限endtime_
关键字：仅限endtime_
重点：9
ref:NULL
行数：21270
额外：在何处使用；使用文件排序

仅限价格

id:1
选择类型：简单
表：易趣商品
类型：索引
可能的_键：NULL
关键字：仅限价格
重点：5
ref:NULL
行数：100000
额外：使用where
身份证号码：1
show indexes on ebay_items;

*************************** 7. row ***************************
Table: ebay_items
Non_unique: 1
Key_name: endtime
Seq_in_index: 1
Column_name: endtime
Collation: A
Cardinality: 230697
Sub_part: NULL
Packed: NULL
Null: YES
Index_type: BTREE
Comment: 
*************************** 8. row ***************************
Table: ebay_items
Non_unique: 1
Key_name: endtime
Seq_in_index: 2
Column_name: price
Collation: A
Cardinality: 230697
Sub_part: NULL
Packed: NULL
Null: YES
Index_type: BTREE
Comment: