在MySQL中，WHERE子句中列的顺序会影响查询性能吗？

我在某些具有较大可能结果集的数据库查询中遇到性能问题。

有问题的查询，我AND在WHERE子句中有三个

条款的顺序重要吗？

与之类似，如果我将ASI_EVENT_TIME子句放在第一位（因为这样会从所有子句中删除大部分结果。

这会改善查询的运行时间吗？

查询：

SELECT DISTINCT  activity_seismo_info.* 
FROM `activity_seismo_info` 
WHERE 
    activity_seismo_info.ASI_ACTIVITY_ID IS NOT NULL  AND 
    activity_seismo_info.ASI_SEISMO_ID IN (43,44,...,259) AND 
    (
        activity_seismo_info.ASI_EVENT_TIME>='2011-03-10 00:00:00' AND 
        activity_seismo_info.ASI_EVENT_TIME<='2011-03-17 23:59:59'
    ) 

ORDER BY activity_seismo_info.ASI_EVENT_TIME DESC

查询说明：

+----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+ 
| id | select_type | table   | type  | possible_keys             | key          | key_len | ref  | rows  | Extra                       |
+----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+ 
|  1 | SIMPLE      | act...o | range | act...o_FI_1,act...o_FI_2 | act...o_FI_1 | 5       | NULL | 65412 | Using where; Using filesort |
+----+-------------+---------+-------+---------------------------+--------------+---------+------+-------+-----------------------------+

使用：

PHP 5.2

MySQL 5.0.51a-3ubuntu5.4

推进1.3

Symfony 1.2.5

我不这么认为。查询优化器应该足够聪明。

您可以尝试重新排列WHERE子句，看看每种情况下EXPLAINS都会告诉您相同的内容。

关于如何优化此查询：ASI_EVENT_TIME是否有索引？（这是我认为对于此查询最关键的，因为您还可以使用它对结果进行排序）。

在其他两个字段（ASI_SEISMO_ID和ASI_ACTIVITY_ID）上是否有索引？

如果您发布表结构，这将很有帮助。

从文档中：

如果表具有多列索引，那么优化器可以使用索引的任何最左前缀来查找行。例如，如果在（col1，col2，col3）上有一个三列索引，则在（col1），（col1，col2）和（col1，col2，col3）上都有索引搜索功能。

如果列不构成索引的最左前缀，则MySQL无法使用索引。

所以是的，它应该与复合索引中列的顺序相同。

不，没关系。

优化器在解析SQL之后立即进行了一系列简单的转换-这就是其中之一。

foo和bar在哪里

与优化相同

酒吧和foo

然而，

非等号＃1和非等号＃2

无法同时优化两个部分。例如，

在1和3之间且b> 17之间

无法充分利用INDEX（a，b）或INDEX（b，a）

换句话说，首先使用WHERE子句中与在一起的所有“ =”测试，然后再处理一个非“ =”（IN，BETWEEN，>等）。最多可以有效地优化一个。

您的查询包含3个此类子句。

事实证明，INDEX（EVENT_TIME）可能是最有用的-它可以帮助AND之一，并且可以用来避免ORDER BY的“文件排序”。

如果没有重复的行（为什么会有重复的行？），请摆脱DISTINCT。这需要更多的努力。

在询问性能问题时，请提供SHOW CREATE TABLE和SHOW TABLE STATUS。

更新... 在某些情况下，较新的版本（例如MySQL 5.7）IN( list of constants )几乎可以像对待=。为了安全起见，请遵循以下顺序（每个部分都是可选的）：

1. 任意数量的=。
2. 有的INs。
3. 最多一个范围。

MySQL的优化文档说：

您可能会想重写查询以使算术运算更快，同时又牺牲了可读性。由于MySQL自动进行类似的优化，因此您通常可以避免这项工作，而将查询保留为更易于理解和维护的形式。MySQL执行的一些优化如下：

• ...

• 对于联接中的每个表，构造一个更简单的WHERE 以获得表的快速WHERE评估，并尽快跳过行。

• 查询每个表索引，并使用最佳索引，除非优化程序认为使用表扫描更有效。一次使用扫描是基于最佳索引是否跨越了表的30％以上，但是固定百分比不再决定使用索引还是扫描。现在，优化器更加复杂，其估计基于其他因素，例如表大小，行数和I / O块大小。

这样，查询优化器就可以合理地省略我们在查询中使用的列的HOW顺序（不仅是MySQL，而且SQL是一种声明性语言，必须做我们想做的而不是我们想做的）。

但是，我仍然喜欢对查询中的复合键的列进行相同的排序，但是有时这是不可避免的，例如当我们使用ORM或ActiveRecord时，在诸如yii2之类的某些框架中，自定义关系标准将附加到处于“开启”状态，但我们仍然需要应用程序不同部分中的QueryBuilder功能。

必须索引在WHERE / HAVING子句中使用的，具有高选择性（唯一值的数量/记录的总数> 10％〜20％）的任何字段。

因此，如果您的ASI_EVENT_TIME列有许多可能的值，请首先将它们全部索引。然后按照@ypercube的说明，尝试重新排列它们，看看EXPLAIN会告诉您什么。应该都是一样的。

另外，希望您看看索引SQL LIKE过滤器。尽管这不是您需要的答案，但是您仍将了解索引的工作原理。

* 编辑： 请参阅下面注释中提供的链接，以了解有关索引的更多信息。