想支持特殊字符录入，写了个小脚本改了下数据库字符集，没想到竟然搞出个大故障。。。
客户要求支持录入特殊字符
前几天搞了个小需求，主要是客户想要支持一些特殊字符的录入。
由于项目当时建库时指定的字符集是utf8，导致目前并不支持特殊字符的录入。
一个脚本轻松搞定
咱一拍脑门，这把各表存储字符信息的字段编码设置为utf8mb4不就得了吗
看把我机智的，都想给自己加工资了！
所以写了个脚本，测试能支持特殊字符录入后，就开始开心的摸鱼了
升级后爆炸了
半夜正做着升职加薪的美梦，突然钉钉电话把我搞醒，现场同事反馈新功能升级后，客户发现部分页面打开报错，并给了我们相关日志文件。
发生甚么事了？
我赶忙翻起来，查看日志显示是部分SQL超时，且CPU占用率居高不下。
欸？这有几个sql查询没有走索引。
不对啊，这个字段是有索引的，怎么好像失效了？
赶紧看下执行计划，我去，居然有个convert！！！
不会是改了字符集导致的吧？看了下表结构，果然两个表字符集不一致。。。
那就没错了。。。根本原因在于相关表字符集不一致导致索引失效，进而导致SQL超时报错。
故障解决
赶紧和现场同事沟通，通知其进行回滚数据库表字符集的修改。
回滚为UTF8后CPU使用率大幅下降，相关页面服务也恢复正常了。
为何修改了个字符集就索引失效了呢？
因为关联查询的两张表字段字符集不一致，这时候就需要进行转换。
而转换本质是一个函数操作，对索引字段进行函数操作就必然导致索引失效。
知识点总结
数据库开发规范-字符集相关：
1.字符集统一使用 utf8mb4，字符集校对统一使用 utf8_general_ci。
统一使用utf8mb4( 5.5.3 版本以上支持 ) 兼容性更好，统一字符集可以避免由于字符集转换产生的乱码。不同的 字符集 进行比较前需要进行 转换 会造成索引失效。
2.生产环境严禁随意修改字符集，修改前需反复确认方案可行性。
3.字符集只能从小往大修改。
索引失效的一般原因总结
1.计算、函数、类型转换(自动或手动)导致索引失效
2.范围条件右边的列索引失效
3.不等于(!= 或者<>)导致索引失效
4.is null可以使用索引，is not null无法使用索引
5.like以通配符%开头索引失效
6.OR 前后只要存在非索引的列，都会导致索引失效
7.数据库和表的字符集不一致 ，转换 会造成索引失效