选择合适的索引顺序至关重要
我们遇到的最容易引起困惑的问题就是索引列的顺序。正确的顺序依赖于使用该索引的查询，并且同时需要考虑如何更好地满足排序和分组的需要。在一个多了 B-Tree 索引中，索引可以按照升序或者降序进行扫描，以满足精确符合顺序的 ORDER BY、GROUP BY 和 DISTINCT 等子句的查询需求。所以多列索引的列顺序至关重要。
对于如何选择索引的列顺序有一个经验法则：将选择性最高的列放到索引最前列。这个经验法则在某些场景可能有帮助，但通常不如随机 IO 和排序那么重要，考虑问题需要更全面（场景不同则选择不同，没有一个放之四海皆准的法则。）
当不需要考虑排序和分组时，将选择性最高的列放在前面通常是很好的。这时候索引的作用只是用于优化 WHERE 条件的查找。在这种情况下，这样设计的索引确实能够最快地过滤出需要的行，对于在 WHERE 子句中只是用了索引部分前缀列的查询来说选恶性也更高。然而，性能不只是依赖于所有索引列的选择性（整体基数），也和查询条件的具体值有关，也就是和值的分布有关。
如何判断一个系统创建的索引时合理的？
一般来说，我们建议按响应时间来对查询进行分析。找出那些消耗最长时间的查询或者那些给服务器带来最大压力的查询，然后检查这些查询的 schema、SQL 和索引结构，判断是否有查询扫描了太多的行，是否做了很多额外的排序或者使用了临时表，是否使用随机 I/O 访问数据，或者是有太多回表查询那些不在索引中的列的操作。