mysql必须要带索引哈，不然会很容易出大问题，平时每个都要通过explain执行下，讲个项目遇到的问题哈
1、前段时间，因为上海疫情原因，所以小米钱包向用户推送了65万条消息，需要他们实名认证后方可以乘车刷卡，然后导致数据库cpu使用率达到100%，我们平时就40左右，然后70就是告警需要分析，100是大问题了，需要回溯问题，检讨，改进措施等了。
2、通过查询sql模板，发现那段有大调用量的就是有个联合sql，select * from a join b on a.issuerId = b.issuerId,2个表都是小表，各自1000条记录，然后使用这个表的接口平时调用量也很少，高峰也就300条，但是那天因为64万条消息给用户，发生cpu问题前2分钟调用量超过100倍，有30万接口进来，2分钟内这么多，并发量很高了
3、分析：即使30万流量2分钟内对于我们每天几百万的流量不算什么的，而且表数据也少，那为什么还cpu影响这么大呢
原因：join on ，on的2个字段都必须加索引，即使数据流小，我们a表加了索引，b表就没有加，然后即使a表有索引，每次查询还是会产生笛卡尔积，1000*1，还是全表查询。
4、发现问题：我们在性能环境验证，首先将a表索引和b表索引都去掉，这个sql一执行马上100%cpu使用率，单独加一个索引，差不多是70的cpu使用率，然后过一段时间又100%了，然后我们2个都加上索引，好，cpu使用率就30左右，保持了正常水平。
结论：join on的on字段需要前后都加上索引，否则还是全表扫描。大量的接口流量进来带来大量的低效sql执行，导致cup使用率100%
继续说下会让索引失效的情况，sql优化整理的
1、where order by,group by后面都加上索引，否则就是全表扫描
2、使用in (2,3),会让索引失效
正确：id between 2 and 3
3、id = 2 or id =3
正确：id = 2 union id =3
4、id in 子查询，子查询返回是false，true是否存在这种，你使用id exsit 子查询即可，否则也是索引失效
5、where id =null,这种也会失效
6、=左边用了函数或者计算，就不行，换到右边
7、id>3，你可以写成id >=4,不要小看这个，他查找位置就性能就高了一点了
8、like 模糊查询，不能前后都包围，一般是后面包围，比如：like aaa%
9、索引不要超过6个，否则就去分析下为什么吧，该删除的索引就删除掉了需要