MySQL索引优化策略（三）：索引列的次序该如何排列更合适？

在众多困扰索引使用的原因中，其中最常见的一个是索引中列的次序。正确的次序依赖于使用索引的查询，因此需要考虑怎样选择索引次序以便数据行的排序火分组能够从中受益（这个仅在二叉树索引有用，哈希索引和其他类型的索引并没有像二叉树索引那样对数据进行排序）。

在二叉树索引中多列的顺序意味着会首先对最左列进行排序，然后才是其他列。因此，为满足ORDER BY，GROUP BY和DISTINCT的条件的查询，索引可能会按正向或逆向扫描进行排序。

结果就是，索引列的次序在多列索引中极其重要。这个次序有可能强化或弱化性能。接下来会通过很多例子说明这种情况。有一个古老的值得推荐的原则：将最具筛选性的列放在索引的第一位。这个建议多有用？在某些例子中是有用的，但是与避免随机I/O和排序相比，就没有那么重要了（有很多特殊的例子，因此没有一个普适性的原则。这里只是告诉你这个原则未必有你想的那么重要）。

在没有排序和分组的时候，将最具筛选性的列放在第一位会是一个好主意，因为这时候索引仅仅是优化WHERE条件的查询。在这类场景下，这样的索引确实能够足够快地筛选出想要的数据。然而，这不仅仅依赖于列的筛选性，还同样依赖于查找数据行的值——值的离散性。这和我们选择一个好的前缀索引长度是类似的。你可能会需要选择一个合适的索引列次序去尽可能地满足最频繁查询的筛选性。

以下面的查询为例：

SELECT * FROM payment WHERE staff_id = 2 AND customer_id = 584;

你应该在(staff_id, customer_id)创建一个索引或者是以相反的次序创建索引吗？我们可以运行一些查询去检查数据表数据的离散性来决定哪个次序更具备筛选性。让我们将查询转换一下，去统计候选项的数量：

SELECT SUM(staff_id = 2), SUM(customer_id = 584) FROM payment;
--------------------------------------------------------------
SUM(staff_id =