一 问题描述

发现生产有这样一个慢查询：

SELECT

  t.*,

  u.user_truename AS username

FROM

  cms_template_flow t

  LEFT JOIN sys_user u

    ON t.create_user_id = u.user_id

WHERE t.wid = 'WS598636079746125824'

  AND t.is_published = 1

ORDER BY t.sortnum DESC

查询需要执行3秒，比较慢。

sys_user有40多万条数据，cms_template_flow只有60条数据。

执行计划如下：

sys_user表的user_id是有建索引的，可是这里却走了全表扫描。

二 排查思路

查看下这两个关联表关联字段的数据类型是否一致，字符集是否一致，collate是否一致

经查看，字符集不一致：

cms_template_flow表的字符集是utf8mb4,sys_user表的字符集是utf8，且这俩表各字段的字符集都未单独设置，因此和其所在表的默认字符集是一样的。

cms_template_flow列create_user_id的字符集是utf8mb4,和sys_user列user_id的字符集(utf8)不一致，导致无法走索引，会多次全表扫描sys_user，性能较差。

三 解决办法

修改其中一个的字符集，和另外一个保持一致。
这里将cms_template_flow列create_user_id的字符集修改为utf8：
ALTER TABLE cms_template_flow CHANGE create_user_id create_user_id VARCHAR(50) CHARACTER SET  utf8 DEFAULT NULL COMMENT '添加人';

执行时间从3秒变成了0.02秒。

最后

以上就是昏睡唇膏为你收集整理的Mysql sql优化案例之表关联字段字符集不同导致被驱动表无法走索引一 问题描述二 排查思路三 解决办法的全部内容，希望文章能够帮你解决Mysql sql优化案例之表关联字段字符集不同导致被驱动表无法走索引一 问题描述二 排查思路三 解决办法所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。