创建高性能的索引
多列索引
很多人对多列索引的理解都不够。一个常见的错误就是，为每个列创建独立的索引，或者按照错误的顺序创建多列索引。先来看第一个问题，为每个列创建独立的索引，从SHOW CREATE TABLE总很容易看到这种情况:
CREATE TABLE t (
c1 INT,
c2 INT ,
c3 INT,
KEY(c1),
KEY(c2),
KEY(c3)
);
这种索引策略，一般是由于人们听到一些专家诸如"把WHERE条件里面的列都建上索引"这样模糊的建议导致的.实际上这个建议是非常错误的。这样一来最好的情况也只能是一星索引，其性能必去真正最优的索引可能差几个数量级。有时如果无法设计一个三星索引，那么不如忽略掉WHERE子句，集中精力优化索引列的顺序，或者创建一个全覆盖索引。在多个列上建立独立的单列索引大部分情况下并不能提高MySQL的查询性能。MySQL5.0和更新版本引入了一种"索引合并"(index merge)的策略，一定程度上可以使用表上的多个单列索引来定位指定的行。更早版本的MySQL只能使用其中某一个单列索引，然而这种情况没有哪一个独立的单列索引是非常有效的。例如，表fime_actor在字典fim_id和actor_id上各有一个单列索引。但对于下面的这个查询WHERE条件，这两个单列索引都不是好的选择:
CREATE TABLE t (
c1 INT,
c2 INT ,
c3 INT,
KEY(c1),
KEY(c2),
KEY(c3)
);
在老的MySQL版本中，MySQL对这个查询会使用全表扫描。除非改写成如下的两个查询UNION的方式:
mysql> SELECT film_id,actor_id FROM film_actor WHERE actor_id = 1
UNION ALL
SELECT film_id,actor_id FROM film_actor WHERE film_id =1 AND actor_id <>1;
但在MySQL5.0和更新的版本中，查询能够同时使用这两个单列索引进行扫描，并将结果进行合并。这种算法有三个变种:OR条件的联合(union),AND条件的相交(intersection),组合前两种情况的联合及相交。下面的查询就是使用了两个索引扫描的联合，通过EXPLAIN中的Extra列可以看到这点:
mysql> EXPLAIN SELECT film_id,actor_id FROM film_actor WHERE actor_id = 1 OR film_id =1\G
*************************** 1. row ***************************id: 1select_type: SIMPLEtable: film_actorpartitions: NULLtype: index_merge
possible_keys: PRIMARY,idx_fk_film_idkey: PRIMARY,idx_fk_film_idkey_len: 2,2ref: NULLrows: 29filtered: 100.00Extra: Using union(PRIMARY,idx_fk_film_id); Using where
1 row in set, 1 warning (0.00 sec)
MySQL会使用这类基数优化复杂查询，所以在某些语句的Extra列中还可以看到嵌套操作。
索引合并策略有时候是一种优化的结果，但实际上更多时候说明了表上的索引建的很糟糕:
- 1.当出现服务器对多个索引做相交操作时(通常有多个AND条件)，通常意味着需要一个包含所有相关列的多列索引，而不是多个独立的单列索引
- 2.当服务器需要对多个索引做联合操作时(通常有多个OR条件)通常需要耗费大量CPU和内存资源在算法的缓存、排序和合并操作上。特别是当其中有些索引的选择性不高，需要合并扫描返回的大量数据的时候
- 3.更重要的是，优化器不会把这些计算到"查询成本"(cost)中，优化器只关心随机页面读取。这会使得查询的成本被"低估"，导致该执行计划还不如直接走全表扫描。这样做不但会消耗更多的CPU和内存资源，还可能会影响查询的并发性，但如果是单独运行这样的查询则往往会忽略对并发性的影响。通常来说，还不如像在MySQL4.1或者更早的时代一样，将查询改写成UNION的方式往往更好
如果在中看到有索引合并，应该好好检查一下查询和表的结构，看是不是已经是最优的。可以通过参数optimizer_switch来关闭索引合并功能，也可以使用IGNORE INDEX提示让优化器忽略掉某些索引
选择合适的索引列顺序
我们遇到最容易引起困惑的问题就是索引列的顺序。正确的顺序依赖于使用该索引的查询，并且同时需要考虑如何更好地满足排序和分组的需要(以B-Tree索引为例)。在一个多列B-Tree索引中，索引列的顺序意味着索引首先按照最左列进行排序，其次是第二列，等等。所以索引可以按照升序或者降序进行扫描，以满足精确符合列顺序的ORDER BY 、GROUP BY和DISTINCT等子句的查询需求。所以多列索引的列顺序至关重要。在Lahdenmaki和Leach的"三星索引"系统中，列顺序也决定了一个索引是否能够成为一个真正的"三星索引".对于如何选择索引的列顺序有一个经验法则:将选择性最高的列放到索引最前列。这个建议有用吗？在某些场景可能有帮助，但通常不如避免随机IO和排序那么重要，考虑问题需要更全面(场景不同则选择不同，没有一个放之四海而皆准的法则。这里只是说明，这个经验法则可能没有你想象的重要)。当不需要考虑排序和分组时，将选择性最高的列放在前面通常是很好的，这时候索引的作用只是用于优化WHERE条件的查找。在这种情况下，这样设计的索引确实能够最快地过滤出需要的行，对于在WHERE子句中只适用了索引部分前缀列的查询来说选择性也更高。然而，性能不只是依赖于所有索引列的选择性(整体基数)，也和查询条件的具体值有关，也就是和值的分布有关，可能需要根据那些运行频率最高的查询来调整索引列的顺序，让这种情况下索引的选择性最高。以下面的查询为例:
mysql> SELECT * FROM payment WHERE staff_id = 2 AND customer_id =584;
是应该创建一个(staff_id,customer_id)索引还是应该颠倒一下顺序?可以跑一些查询来确定在这个表中值的分布情况，并确定哪个列的选择性更高。先用下面的查询预测一下，看看各个WHERE条件的分支对应的数据基数有多大:
*************************** 1. row ***************************SUM(staff_id=2): 7990
SUM(customer_id =584): 30
根据前面的经验法则，应该将索引列customer_id放到前面，因为对应条件值的customer_id数量更小。我们再来看看对于这个customer_id的条件值，对应的staff_id列的选择性如何:
mysql> SELECT SUM(staff_id=2) FROM payment WHERE customer_id=584\G
*************************** 1. row ***************************
SUM(staff_id=2): 17
这样做有一个地方需要注意，查询的结果非常依赖于选定的值。如果按照上述办法优化，可能对其他一些条件值的查询不公平，服务器的整体性能可能变得更糟，或者其他某些查询的运行变得不如预期。如果是诸如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\G
*************************** 1. row ***************************staff_id_selectivity: 0.0001
customer_id_selectivity: 0.0373COUNT(*): 16044
customer_id的选择性更高，所以答案是将其作为索引列的第一列:
mysql> ALTER TABLE payment ADD KEY(customer_id,staff_id);
