mysql（六）多列索引之索引顺序问题

使用索引常见的错误是

• 为每列创建单独的索引，
• 或者按照错误的顺序创建多列索引

多列索引

多列索引，是指在创建索引时所关联的字段不是一个字段，而是多个字段，虽然可以通过所关联的字段进行查询，但是只有查询条件中使用了所关联字段中的第一个字段，多列索引才会被使用

多列索引时顺序问题

平时我们遇到的比较容易引起困惑的问题就是索引列的顺序。正确的顺序依赖于使用该索引的查询，并且同时需要考虑如何更好的满足排序和分组的需要（针对B-Tree索引）

在一个多列B-Tree索引中，索引列的顺序意味着
索引首先按照最左列进行排序，其次是第二列，等等。所以，索引可以按照升序或者降序进行扫描，以满足精确符合列顺序的 ORDER BY，GROUP BY和DISTINCT等字句的查询需求。

所以多列索引的顺序至关重要。在Lahdenmaki和Leach的“三星索引”系统中，列顺序也决定了一个索引是否能够成为一个真正的“三星索引”

对于如何选择索引的列顺序有一个经验法则：将选择性最高的列放到索引的最前列。这个建议有用吗？在某些场景可能有帮助，但通常不如避免随机IO和排序那么重要，考略问题需要更全面（场景不同则选择不同，没有一个放之四海皆准的法则。这里只能说明，这个经验法则没有你想的那么重要）

当不需要考虑排序和分组时，将选择性最高的列放在前面。这个时候索引的作用只是用于优化WHERE条件的查找。在这种情况下，这样的设计的索引确实能够最快的过滤出需要的行，对于在WHERE子句中只使用了索引部分前缀的列的查询来说选择性也更高。然而，性能不只是依赖于所有索引列的选择性（整体基数），也和查询条件的具体值有关，也就是和值的分布有关。这和选择前桌的长度需要考虑的地方一样。可能需要根据那些运行频率最高的查询来调整索引列的顺序，让这种情况下的索引的选择性最高

演示示例

新建表

CREATE TABLE `payment` (
  `id` int NOT NULL AUTO_INCREMENT,
  `staff_id` int NOT NULL,
  `customer_id` int NOT NULL,
  `money` decimal(20,0) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=169682 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

随机插入数据

此时有如下查询：

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

此时是应该创建一个（staff_id,customer_id）索引还是应该颠倒一下顺序？

此时我们可以跑一下查询来确定在这个表中值的分布情况，并确定哪个列的选择性更高。

先使用以下查询预测一下，看看各个WHERE条件分支应对的数据基数有多大

mysql> select SUM(staff_id=2),SUM(customer_id=584) from payment;
+-----------------+----------------------+
| SUM(staff_id=2) | SUM(customer_id=584) |
+-----------------+----------------------+
|          219555 |                   30 |
+-----------------+----------------------+
1 row in set (0.08 sec)

根据前面的经验法则，应该将索引列customer_id放在前面，因为对应的条件值的customer_id数量更小。我们再来看看对于这个customer_id的条件值，对应的staff_id列的选择性如何

mysql> select sum(staff_id = 2) from payment where customer_id = 584;
+-------------------+
| sum(staff_id = 2) |
+-------------------+
|                17 |
+-------------------+
1 row in set (0.05 sec)

这样做有一个地方需要注意，查询的结果非常依赖于选定的值。如果按照上述办法优化，可能对其他的值的查询不公平，服务器的整体性可能变得更糟糕，或者其他某些查询的运行变得不如预期

如果是从pt-query-digest这样的工具的报告中提取“最差”查询，那么再按照上述的办法选定的索引顺序往往是非常高效的。如果没有类似的具体查询来运行，那么最好还是按经验法则来做,因为经验法则考虑的是全局基数和选择性，而不是某个具体的查询

mysql> select count(distinct staff_id)/count(*) as staff_id_selectivity,count(distinct customer_id)/count(*) as customer_id_selectivity,count(*) from payment;
+----------------------+-------------------------+----------+
| staff_id_selectivity | customer_id_selectivity | count(*) |
+----------------------+-------------------------+----------+
|               0.0001 |                  0.0373| 15543109 |
+----------------------+-------------------------+----------+
1 row in set (1 min 27.19 sec)

customer_id的选择性更高，所以答案是将其作为索引列的第一列：

ALTER TABLE payment ADD KEY(customer_id,staff_id);

当使用前缀索引的时候，在某些条件值的基数比正常值高的时候，问题就来了。例如，在某些应用程序中，对于没有登录的用户，都将其用户名记录为“guest”,在记录用户行为的会话表和其他记录用户活动的表中“guest”就成为了一个特殊用户ID，一旦涉及这个用户，那么和对于正常用户的查询就大不同了，因为通常有很多会话都是没有登录的。系统账号也会导致类似的问题。一个应用通常都有一个特殊的管理员账号，和普通账号不同，他并不是一个具体的用户，系统中所有的其他用户都是这个用户的好友，所以系统往往通过他向网站的所有用户发送状态通知和其他消息。这个账号的巨大好友列表很容易导致网站出现服务器性能问题。

这实际上是一个非常典型的问题。任何的异常用户，不仅仅是那些用于管理应用的设计糟糕的账号会有同样的问题，那些拥有大量好友，图片，状态，收藏的用户，也会有前面提到的系统账号同样的问题

下面举个例子：
在一个用户分享购买商品和购买经验的论坛上，这个特殊表上的查询运行的非常慢：

select count(distinct threadId) as count_value from Message where (group_id = 10137) and (userId = 1288826) and (anonymous = 0) order by priority desc,modifiedDate desc

这个查询看似没有建立合适的索引，所以客户咨询我们是否可以优化。EXPLAIN的结果如下：

         id：1
select_type：SIMPLE
      table：Message
       type：ref
        key：ix_groupId_userId
    key_len：18
        ref：const,const
       rows：1251162
      Extra：Using where

MySQL 为这个查询选择了索引(groupId,userId)，如果不考虑列的基数，这看起来是一个非常合理的选择。但如果考虑一下 user ID 和 group ID 条配的行数，可能就会有不同的想法了 :

mysql> SELECT COUNT(*),SUM(groupId = 10137),SUM(userId = 1288826),SUM(anonymous = 0) FROM Messagel
+----------------------+-------------------------+----------+----------+----------+
|             count(*) |     sum(groupId =10137) | sum(userId=1288826) |sum(anonymous = 0) |
+----------------------+-------------------------+----------+----------+----------+
|              4142217 |                 4092654 |             1288496 |           4141934 |
+----------------------+-------------------------+----------+----------+----------+
1 row in set (1 min 27.19 sec)

从上面的结果来看符合组 (groupId) 条件几乎满足表中的所有行，符合用户(userId)条件的有 130 万条记录一一也就是说索引基本上没什么用。因为这些数据是从其他应用中迁移过来的，迁移的时候把所有的消息都赋予了管理员组的用户。这个案例的解决办法是修改应用程序代码，区分这类特殊用户和组，禁止针对这类用户和组执行这个查询

从这个小案例可以看到经验法则和推论在多数情况是有用的，但要注意不要假设平均情况下的性能也能代表特殊情况下的性能，特殊情况可能会摧毁整个应用的性能。

最后，尽管关于选择性和基数的经验法则值得去研究和分析，但一定要记住别忘了WHERE子句中的排序、分组和范围条件等其他因素，这些因素可能对查询的性能造成非常大的影响。