摘要
最近遇到一个慢sql，在排查过程中发现和分库分表后的索引设置有关系，总结了下问题。
问题
在进行应用健康度盘点时，发现有个慢sql
如下
select brandgoodid from brandgood_0020
where userid = xxx AND
brandgoodid in("xxx1","xxx2")
表结构,按照userid进行的分表。
CREATE TABLE`brandgood_0020` (
`brandgoodid` char(30) NOT NULL COMMENT ,
`user_id` int(10) unsigned DEFAULT NULL COMMENT '用户id',
`created` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
`last_modified` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`deleted` bit(1) NOT NULL DEFAULT b'0',
PRIMARY KEY (`brandgoodid`),
KEY `idx_userid` (`userid`) USING BTREE,
) ENGINE=InnoDB DEFAULT CHARSET=utf8
explain一下发现走的是userid这个索引，一个用户下面有很多商品，也就有了很多brandgoodid，所以有可能会很慢，因为要扫描很多的索引键去过滤brandgoodid值。
而写这个SQL的人期望走的主键索引，而不是'userid'的索引。因为用主键索引，就是N次主键扫描（N表示in中的数量）。
分析
直接原因很明显
IN 这个查询误导了mysql的优化器，选错了索引
IN 查询常常会影响mysql server的判断。主要是IN里面的值数量不同，会影响扫描行数的不同，所以常常会出现索引选择不一致。之前也总结过一篇SQL IN 一定走索引吗
解决
因为用户查询的brandgoodlid是限定在某个group维度下的，一个group对应的brandgood是有限的，在这个业务中，通常小于10。所以这个地方使用主键索引，效率更高。解决方法也就是这地方需要force index强制走PRIMARY index。
扩展
分库分表后的索引
为什么题目叫分库分表后的索引问题的，直接原因和分库分表并没有什么关系啊？
因为在排查问题时，犯了一个错误。以为路由到具体的brandgood_0020表后，可以直接根据brandgoodid主键索引来查询了。认为和一些分布式数据库(cassandra)一样,是clustering key+partition key这种索引数据。可以根据clustering key到数据的节点的partition块，然后根据local index 找到对应的数据。
但其实mysql的分库分表不一样，分表键不是索引，只是客户端路由。只负责找到对应的表。到表以后，就是和单表一样查询逻辑。
因为分表键不是索引，但是查询语句是必须要带着分表键，那意味着我们的分库分表以后的表索引大部分要建成联合索引了，分表键+索引键。
要不然我们的查询语句 select xx from table where 分表键=xxx AND a =xxx，是走不了联合索引的。只能走单索引。单索引mysql server要面临着索引选择的问题。
当然并不是绝对的，比如上面我举的那个案例。按照这个思路查看了下其他的分表索引。果然表上的大部分索引都是非联合索引，还是直接从单表copy过来的索引。这些索引基本上都是无用的，因为都的是userid索引.
索引选择的问题
mysql为什么会选错索引呢，详细的请看10 | MySQL为什么有时候会选错索引
我们这个案例是因为判断扫描行数的时候出问题了。