前言:
收到疯狂的慢查询及请求超时报警，通过metrics分析出来自mysql请求的异常，cli —> show proceslist 看到很多慢查询。 先前该sql是没有的，后面因为数据量的增长才出现了这问题。 虽然feeds表大到一个亿，但因为feeds流信息有近期热的特征，所以不是因为 innodb_buffer_pool_size 低效引起的io频繁。 后来经过进一步explain执行计划分析得出了原因，mysql查询优化器选择了他认为高效的索引。
mysql查询优化器大多数情况是靠谱的! 但是你的sql语言含有多个索引时就要注意了，往往最后的结果令人有些彷徨了。因为mysql同一个sql只能使用一个索引，那么选择哪个呢？ 在数据量小时候，mysql优化器会把主键索引后置，优先使用 index和unique 。 当你达到一个数据量级后，又因为你的查询操作有 in ，那么mysql查询优化器很可能会选用主键的 ！
记住一句话，mysql查询优化是基于检索成本考虑，而不是基于时间成本考虑。 优化器是根据现有的数据状态来推算代价，而不是真的去执行一遍sql.
所以，mysql优化器并不是每次都可以达到优化的效果的。 它并不能准确预估代价，如果要准确得到走各个索引的代价就要去真的执行一遍才能知道，所以代价分析只是做了一个预估，既然是预估那么就有误判。
我们这里说的表是feed信息流表，我们知道feeds信息流表访问不仅频繁，而且数据量也很大。 但是这个表的数据结构很简单，索引也简单. 一共就两个索引，一个是主键索引， 一个是unique唯一键索引。
如下，该表的量级已经到亿级别了，因为有足够多的cache前顶，又因为这样那样的原因，所以没来的及做分库分表。
问题是这样的， 当数据量级不到一个亿的时候，mysql优化器选择使用 index索引， 当数据量级超过一个亿后，mysql查询优化器选择使用 主键索引了。 这样带来的问题就是 查询速度太慢。
这是正常情况下:
| mysql> explain SELECT * FROM `feed` WHERE user_id IN (116537309,116709093,116709377) AND cid IN (1001,1005,1054,1092,1093,1095) AND id <= 128384713 ORDER BY id DESC LIMIT 0, 11 /G;*************************** 1. row *************************** id: 1 select_type: SIMPLE table: feed partitions: NULL type: rangepossible_keys: PRIMARY,feed_user_target key: feed_user_target key_len: 6 ref: NULL rows: 18 filtered: 50.00 Extra: Using where; Using index; Using filesort1 row in set, 1 warning (0.00 sec) |
同样的sql语句，在数据量有较大变化后，mysql查询优化器对索引的选择也有了变化。
| mysql> explain SELECT * FROM `feed` WHERE user_id IN (116537309,116709093,116709377) AND cid IN (1001,1005,1054,1092,1093,1095) AND id <= 128384713 ORDER BY id DESC LIMIT 0, 11 /G;*************************** 1. row *************************** id: 1 select_type: SIMPLE table: feed type: rangepossible_keys: PRIMARY,feed_user_target key: PRIMARY key_len: 4 ref: NULL rows: 11873197 Extra: Using where1 row in set (0.00 sec) |
