MySQL：为什么简单查询不使用索引，而是执行文件排序

我有一个定义如下的表：

`id` int(10) NOT NULL AUTO_INCREMENT,
`slug` varchar(150) NOT NULL,
`title` varchar(150) NOT NULL,
`description` text NOT NULL,
`ordinal` int(10) NOT NULL DEFAULT '0'

让我们称之为t1

在t1中，我有一个关于序号的索引

这个表只包含几行，它是一个定义表，所以我通常这样做，以获得我想要的顺序的定义

SELECT * FROM t1 WHERE 1 ORDER BY ordinal;

如果我对该语句执行解释，我会得到以下结果：

id? select_type?    table?  partitions? type?   possible_keys?  key?    key_len?    ref?    rows?   Extra?
1   SIMPLE  t1  NULL    ALL NULL    NULL    NULL    NULL    5   Using where; Using filesort

上面这一行是否对齐并不重要。重要的是它正在使用文件排序，我不知道为什么

因为这个表中只有5-10行，所以感觉它并不重要，但是filesort让我的open\u表变得有点疯狂，因为MySQL（根据强大的互联网）为它需要执行的每个filesort查询打开了两个表

---

所以，非常感谢你的帮助。谢谢。

您的表在“序号”列上没有任何可能被利用的索引。此外，由于WHERE子句位于一个固定的“1”值上，该值始终为真，但没有可比较的列，甚至没有可帮助查找索引的列，因此它无法选择任何内容。。。所以你要通过一个文件排序。。。没有适用于where和order by子句的索引。

您有5行。我想在这么小的数据集上使用索引是不麻烦的。计划中提到“使用where”，这有点危险，因为你的

where

子句每一行都满足要求。优化器在分析如何以及是否使用索引时，可能会关注连接和选择谓词。您的索引可能会被忽略，因为它对这些没有帮助。删除<<代码> 完全可以说服它考虑< <代码>命令> <代码> >的索引。或者，因为只有几行，MySQL无论如何都要读取它们，所以直接对它们进行排序可能会更快。但是，删除“where 1”并没有帮助。奇怪的是，我真的不希望它像创建filesort那样创建一个tmp表，因为我有一个“开放表”问题，这似乎部分来自于这些具有filesort的查询。索引在那里，我只是没有把它放在上面的文本中。我的主要问题是如何避免文件排序，因为它附带了bagage。不过还是要感谢你写了一个答案。@Adergaard，通过尝试根据预期的查询条件建立计划良好的索引来避免文件排序。此外，还要学习使用复合索引和覆盖索引。当处理总计和聚合时，尤其是在web中，不要害怕使用更高级别的总计/计数列，以防止不断查询基础详细信息。