Mysql的联合索引-最左匹配的隐藏规则

联合最左匹配原则

1. 最左前缀匹配原则，很是重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就中止匹配，好比a = 1 and b = 2 and c > 3 and d = 4 若是创建(a,b,c,d)顺序的索引，d是用不到索引的，若是创建(a,b,d,c)的索引则均可以用到，a,b,d的顺序能够任意调整。

2. =和in能够乱序，好比a = 1 and b = 2 and c = 3 创建(a,b,c)索引能够任意顺序，mysql的查询优化器会帮你优化成索引能够识别的形式。

3. 尽可能选择区分度高的列做为索引，区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大咱们扫描的记录数越少，惟一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不一样，这个值也很难肯定，通常须要join的字段咱们都要求是0.1以上，即平均1条扫描10条记录。

4. 索引列不能参与计算，保持列“干净”，好比from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，缘由很简单，b+树中存的都是数据表中的字段值，但进行检索时，须要把全部元素都应用函数才能比较，显然成本太大。因此语句应该写成create_time = unix_timestamp(’2014-05-29’)。

5. 尽可能的扩展索引，不要新建索引。好比表中已经有a的索引，如今要加(a,b)的索引，那么只须要修改原来的索引便可。

6. 匹配某列的前缀索引，此时能够用到索引，可是若是通配符不是只出如今末尾，
   则没法使用索引。

一组和原则相悖的实验

建立一个表，字段：

CREATE TABLE `abc` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `a` varchar(64) DEFAULT NULL,
  `b` varchar(64) DEFAULT NULL,
  `c` varchar(64) DEFAULT NULL
  PRIMARY KEY (`id`),
  KEY `idx_abc` (`a`,`b`,`c`) USING BTREE
) ENGINE=InnoDB  ;

正常的查询

explain select * from abc t where t.a='a' and t.b='b' and t.c='c'; // 三列索引
explain select * from abc t where t.a='a'  and t.b='b'; // 2列
explain select * from abc t where t.a='a'  and t.c='c';//1列
explain select * from abc t where t.a='a'; //1列
explain select * from abc t where t.b='b'; // 0列
explain select * from abc t where t.c='c'; // 0列
explain select * from abc t where t.a='a'  and t.c='c'and t.b>'b'; // 2列

以上查询都可按照正常的最左索引进行。

不符合原则的查询

explain select * from abc t where  t.b='b' and t.c='c';

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	t	index		idx_abc	201		476	Using where; Using index

结论很奇怪：按最左原则，b和c的查询，因为没有用到a列，因此不该该命中索引。

神奇的地方

ALTER TABLE `test`.`abc` 
ADD COLUMN `d` varchar(255) NULL AFTER `c`;
commit;
explain select * from abc t where  t.b='b' and t.c='c';

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	t	ALL					476	Using where

这轮索引没有命中，就由于多了一个字段吗？

猜测

1. 当表中全部字段均在索引范围内，不管如何查询，都会试图用索引去提速。
2. B+Tree在构建的时候，对所有字段有特殊处理。