标签：knowledge default Mysql 字符集 调优 base 简单 operation log

第一次写博客，有漏洞的地方希望大佬指正

背景:优化公司老系统中的一条慢sql,查看执行过程如下:

sql虽然比较简单，平时执行也没发现什么问题，但一到生产环境系统频繁调用，问题就显现出来了，整个系统停滞不前，打开Navicat的服务器监控发现里面出现好多执行中的sql甚至出现死锁

查看knowledge_default_operation_log表发现数据10多万条，knowledge_base_info表1万多条，由第第一张图可以明显的看出knowledge_default_operation_log表没有走索引，查看该表发现knowledge_base_id字段上有索引，怎么回事？

根据以往的经验又查看knowledge_base_id与knowledge_id的字段类型，没问题都是varchar类型啊，往下看发现了问题所在

统一修改排序规则为utf8_general_ci及最终调整sql结构后执行结果如下：

执行时间平均在0.17s左右，线上该模块慢查询消失，网上查看资料得知

由于knowledge_default_operation_log表取出的knowledge_base_id字段是utf8_general_ci字符集，而knowledge_base_info表里面的knowledge_id是utf8_bin字符集，这里需要做字符集转换，字符集转换遵循由小到大的原则，两者可能存在字符转换，转换了之后，由于knowledge_default_operation_log上面的索引仍然是utf8_general_ci字符集，所以这个索引就被执行计划忽略了，然后knowledge_default_operation_log表只能选择全表扫描。knowledge_base_info表如果筛选出来的记录不止1条，那么knowledge_default_operation_log就会被全表扫描多次，性能就变慢了。

结尾注意：生产环境修改字符集不能用alter table xx charset utf8_general_ci，因为生产执行的查询比较多会引起阻塞，另外也不能修改已经存在字段值的字符集，我是在业务低峰时期用pt-online-schema-change改的。

标签：knowledge,default,Mysql,字符集,调优,base,简单,operation,log
来源： https://www.cnblogs.com/etoumao/p/14014515.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。