6、mysql遇到的坑&MRR（有问题待解决）

1、（没懂）线上数据库主键自增步长是2，可能会导致分表间数据量分布不均匀

例如：用户表userId自增，订单按userId分表，userId自增步长是2，订单分表是1024，那么最多一半表有数据，奇数分表肯定没数据。

dba解释是，在主库故障主从切换时，为了防止主键冲突，所以加了这条规则。例如，主库目前主键是 0，2， 4， 6， 8， 10 。。。。，切换从库后主键变成 11，13，15，17，19.。。。；在切换过程中，可能老主库还有部分 12，14，16.。 在写，为了防止切换过程中新老主库同时写主键冲突，所以自增步长是2；

2、线上 mrr 默认是关闭的，dba还是建议开启的，尤其二级索引范围查询性能会好

开启mrr需要dba操作，set global optimizer_switch='mrr=on,mrr_cost_based=off'; 重启dbproxy生效。

二、MRR

MySQL 5.6提供了很多性能优化，如Multi-Range Read 多范围读(MRR) , 针对基于辅助索引的查询，减少随机IO，将随机IO转化为顺序IO，提高查询效率。

原理：

在没有MRR前基于辅助索引查询策略：select non_key_column from tb where key_column=x;

1、根据where条件中辅助索引获取辅助索引与主键的集合，结果集为rest。

2、 通过第一步获取的主键获取对应值

辅助索引并非与主键的存储顺序一致，获取的主键来访问数据会导致随机IO . 不同主键不在同一个page 导致多次IO 和随机读。

MRR优化特性

1、同上： select key_column,pk_column from tb where key_column=x order by key_column

2、结果集rest放在buffer里(read_rnd_buffer_size 大小直到buffer满了)，然后对结果集rest按照pk_column排序，得结果集rest_sort

3、用已排序结果集，访问数据，顺序IO.select non_key_column from tb where pk_columnin(rest_sort)

满足一次read_rnd_buffer_size中的数据检索是磁盘IO读取有序的。

优化器的使用场景：

1 type = range access (已经证实)

2 type = ref and eq_ref access, 当使用BKA(Batched Key Access),使用到连接索引，键值唯一(非主键)或者不唯一或者使用组合索引前缀

开启MRR命令:   set optimizer_switch='mrr=on,mrr_cost_based=off';

使用场景：

只有Text字段没有索引。

gender 是索引键，但没走MRR，因为查询优化器会根据 type的属性进行判断，不是range的话是不会走MRR的。

explain select * from member where gender=1;

没走

走