最近小崔在忙着赶需求的路上（ps：boss太狠了，一个星期一个版本），刚好项目测试环节结束，项目也部署到预发布环境，本想万事大吉，咱们愉快又轻松的学习下吧！
噩耗来了，同事反应有个接口的响应速度尽然达到了恐怖的十几秒，同事迅速定位了下问题，发现是小崔对外提供的接口响应太慢了。哇哦，小崔顿时慌了，连忙查看这个接口，发现这个接口下面只执行了下面这段代码
小崔心想，测试环境好好的，怎么到了预发布环境接口响应速度怎么就差了这么多呢。所以小崔迅速去对比了下这张表的数据量，不看不知道，一看吓一跳。预发布环境的数据量尽达到了390多万条数据，这可是测试环境的好几十倍呢。
这下子相信有些大佬已经猜出问题所在了。下面就是这张表的索引结构
程序执行的SQL如下：
SELECT * from www_member WHERE mobileNumber = 'xxxxx' AND channelId in('xxx','xxx','xxx')
没错，就是这条SQL在执行的时候没有走索引，进行了全表扫描，因此，这条SQL整整执行了十几秒。
所以这肯定是一条慢SQL，这时小崔想起了老大教的解析慢SQL的步骤：
1、使用explain关键字去查看这条SQL的执行计划
EXPLAIN SELECT * from www_member WHERE mobileNumber = 'xxx' AND channelId in('xxx','xxxx','xxx')
执行结果如下：
相信大家也看懂了，这条SQL可能执行的索引位：channel_id_index，但是实际上在‘key’下面没有走索引。
至于为什么没走索引，是因为SQL执行的时候遵循最左原则，当‘mobileNumber’这个字段没有添加索引的时候，尽管后面的‘channelId’字段添加了索引，这条SQL也不会走索引。
哦~，原来如此，这时候其实有两种解决方案
第一种方案是：将in语句挪到前面，我们使用explain看看
这时候你会发现，针对这条SQL还是没有走索引。为什么呢？是不是很纳闷。
其实，索引最好建立在区分度比较高的列上。在这里，由于channelId这列的区分度不高，并且小崔执行的这条SQL匹配的数据超过了总表的30%以上。
因此，这里的in还是没能走索引。
所以只剩下最后一种方案了，由于每个人的手机号都不同，是最适合建立索引的。
小崔迅速在mobileNumber字段上建立的索引，再使用explain关键字查看下，发现果然快多了
快看这个索引级别可以很难达到的喔，哈哈哈
ps：其实mobileNumber字段原来是加了唯一索引，由于业务需求，就将唯一索引删除了。这就
告诉我们写代码的时候千万不要大意，不然后患无穷喔。
幸亏预发布就发现了这个问题，不然小崔估计要走人了。
哈哈，好险好险