问题描述：
公司在使用若依架构，查询角色列表的时候用到了角色列表接口，生产查询时候很慢，大概需要6秒
原始sql:
select distinct r.role_id, r.role_name, r.role_key, r.role_sort, r.data_scope, r.menu_check_strictly, r.dept_check_strictly,
r.status, r.del_flag, r.create_time, r.remark
from sys_role r
left join sys_user_role ur on ur.role_id = r.role_id
left join sys_user u on u.id = ur.user_id
left join sys_dept d on u.dept_id = d.id
where r.del_flag = '0'
原执行计划：
最终通过排查，发现导致慢的原因是：关联字段的字符集编码不一致，通过网上百度和之前也处理过一次sql慢的原因是由于字符集不一致
解决方式：
将sys_user_role的user_id字段的字符集改为utf8,原先为utf8mb4
优化后的执行计划：
mysql中utf8和utf8mb4区别：
MySQL在5.5.3之后增加了这个utf8mb4的编码，mb4就是most bytes 4的意思，专门用来兼容四字节的unicode。好在utf8mb4是utf8的超集，除了将编码改为utf8mb4外不需要做其他转换。当然，为了节省空间，一般情况下使用utf8也就够了。
既然utf8能够存下大部分中文汉字,那为什么还要使用utf8mb4呢? 还要从Unicode编码说起，UCS-2用的是两字节编码，两字节最多只能能表示65535个字符，后来发布的UCS-4用四字节表示，把可表示的字符扩展到了100万以上。原来mysql支持的 utf8 编码最大字符长度为 3 字节，如果遇到 4 字节的宽字符就会插入异常了。三个字节的 UTF-8 最大能编码的 Unicode 字符是 0xffff，也就是 Unicode 中的基本多文种平面(BMP)。也就是说，任何不在基本多文本平面的 Unicode字符，都无法使用 Mysql 的 utf8 字符集存储。包括 Emoji 表情(Emoji 是一种特殊的 Unicode 编码，常见于 ios 和 android 手机上)，和很多不常用的汉字，以及任何新增的 Unicode 字符等等(utf8的缺点)。
