程序员不要好心办坏事

　　开发中我们看那些散发着浓烈的badsmell的代码，总有一种要修理它的冲动！这当然是好事，说明我们有能力识别不好的东西以及维持系统健康运行的意愿。但是，但是总是无处不在，我们好心有时候会办出坏事来。下面这个真实的案例就是某同学觉得表的字符集设计得不合理，在一次需求开发中就把他改了，然而不幸的是由此导致了一个不小的线上事故，下面分享给大家1。事故的导火线
　　你敢想？导致线上事故的是一个简单的DDL语句：
　　ALTERTABLEtabletCONVERTTOCHARACTERSETutf8mb4；2。事故现场
　　由于业务系统响应极慢，使用方反馈（早期系统没有完善的告警机制），开发排查日志发现是sql查询速度很慢，然后查询慢日志监控，看到了如下的壮观场景：
　　慢sql监控信息3。事故原因分析
　　为什么会有这么多慢查询呢？？因为查询语句的关联字段的字符集不同，导致索引失效，sql执行变成了全表扫描，进而导致数据库实例所在机器的CPU长时间100，影响业务访问。4。事故线下重现
　　我们使用连接查询时，两个表的关联字段都建有索引，但是如果两个表的关联字段的字符集不同，就会导致索引失效，不会走索引。执行下面的建表语句：CREATETABLEt1（
　　idbigintNOTNULLAUTOINCREMENT，
　　nameVARCHAR（64）DEFAULT，
　　codeVARCHAR（16）DEFAULT，
　　PRIMARYKEY（id），
　　KEYidxcode（code），
　　KEYidxname（name）
　　）ENGINEInnoDBAUTOINCREMENT6DEFAULTCHARSETUTF8；CREATETABLEt2（
　　idbigintNOTNULLAUTOINCREMENT，
　　nameVARCHAR（64）DEFAULT，
　　codeVARCHAR（16）DEFAULT，
　　PRIMARYKEY（id），
　　KEYidxcode（code），
　　KEYidxname（name）
　　）ENGINEInnoDBAUTOINCREMENT6DEFAULTCHARSETUTF8MB4；
　　然后插入一些数据：INSERTINTOt1（id，name，code）VALUES（6，aa，）；
　　INSERTINTOt1（id，name，code）VALUES（7，bb，）；
　　INSERTINTOt1（id，name，code）VALUES（8，0，）；
　　INSERTINTOt1（id，name，code）VALUES（9，1，）；
　　INSERTINTOt1（id，name，code）VALUES（10，2，）；
　　INSERTINTOt1（id，name，code）VALUES（11，3，）；
　　INSERTINTOt1（id，name，code）VALUES（12，4，）；
　　INSERTINTOt1（id，name，code）VALUES（13，5，）；
　　INSERTINTOt1（id，name，code）VALUES（14，6，）；
　　INSERTINTOt1（id，name，code）VALUES（15，7，）；
　　INSERTINTOt1（id，name，code）VALUES（16，8，）；
　　INSERTINTOt1（id，name，code）VALUES（17，9，）；
　　INSERTINTOt2（id，name，code）VALUES（6，ff，）；
　　INSERTINTOt2（id，name，code）VALUES（7，hh，）；
　　INSERTINTOt2（id，name，code）VALUES（8，gg，）；
　　线上的sql形式如下：
　　selectfromt2leftjoint1ont1。codet2。codewheret2。nameff；
　　我们查看执行计划：
　　explainextendedselectfromt2leftjoint1ont1。codet2。codewheret2。nameff；
　　从下图的执行计划可以看到，查询条件t2。nameff使用了索引，而条件t1。codet2。code并没有使用表t1的索引：
　　sql执行计划
　　为什么两个字段的字符集不一样就不走索引了呢？这个命令SHOWWARNINGS；会给你详细的说明分析，这个命令和执行计划配合使用，简直不能再香了。你一定要去使用！如下：
　　执行的warnings信息
　　message全量内容如下：
　　select1selecttest。t2。idASid，test。t2。nameASname，test。t2。codeAScode，test。t1。idASid，test。t1。nameASname，test。t1。codeAScodefromtest。t2leftjointest。t1on（（convert（test。t1。codeusingutf8mb4）test。t2。code））where（test。t2。nameff）
　　这时候已经非常清楚了，MySQL在关联字段上进行了convert转化，索引当然就失效喽！5。事故解决
　　问题的解决也是简单粗暴，DBA直接改回了原来的字符集：
　　ALTERTABLEttestCONVERTTOCHARACTERSETutf8；6。事故复盘
　　平时让我们说索引失效的场景你可能会咔咔咔地说出不少，但是实际使用的时候却时常会犯错，实际上还是意识不强烈。不管怎么说，都要认真对待自己写下的每行代码，包括任何要上线的资源，如初始化的数据，脚本等。就拿这次事故来说，开发同学本意是觉得utf8字符集不严谨，应该使用utf8mb4，但实际上表中的code字段存储的只是数字和字母组成的字符串，早期历史原因被设计成utf8也无可厚非了。但是，我们作为后来接手者，任何改动就要小心了，避免跳坑里了。
　　OK，咱们回聊