一、缘起
公司部署了一套系统，之前在别的地方部署没有问题，运行正常，但是在济南部署时就出现了问题
出现的问题是：错误日志信息不能插入错误信息的日志表中，导致前台查不到错误信息数据
二、排查
（1）首先查看错误日志查询的sql，确实没有数据产生，这就排除了是前台不加载的问题
（2）之后排查节点状态记录表，发现错误记录的标志产生，但是没有把详情插入另一张表
（3）反推的时候发现，一个文件的流程节点状态本该是五个的，现在变成了10个，翻了一倍，
猜想是数据执行更新的时候，没有执行更新，而是执行了插入
（4）排查到一筹莫展，无奈请了数据库大神来排查
（5）大神果然不同，打开数据库查询数据库进程，发现有一个sql一直执行，从未停止
（6）把sql复制出来，单独执行，确实停不下来，大神在系统里查询数据库的缓存配置【buffer pool size】，调大再试，不行
（7）那会是数据库在linux系统占满导致不能执行的吗？
我们的现场系统占用的都是虚拟机，查看mysql的挂载状态，发现mysql挂到了一个已经占用74%的盘上
大神坚定的说，这就试问题所在，快，把mysql挂到另一个独立的系统分区，软连接到这个地方
把目录下文件移动，改动mysql的【my.cnf】文件，修改文件路径
结果依旧，这就几乎可以排除空间不够和磁盘坏道问题
（8）那sql为什么会执行这么慢？
查看linux系统进程执行状态，看my.cnf文件，
最后大神打开表结构发现是字符集指定成了二进制格式，修改为【utf-8-general-ci后】，4秒完成连接查询和校验，错误信息插入成功
（9）查看发现数据库建库时，字符集指定为bin类型，所以之后过程调用在该数据库建表时，默认使用了该字符集，修改数据库字符集成功
三、总结：
（1）如果发现数据查询很慢，很可能是【字符集设置不正确】，导致数据查询效率极慢，数据量大尤其明显
四、扩展：
（1）大神修改之后感叹，上次他碰到的另一个问题
一次现场系统升级，系统瘫了，发现json解析的时候出了错，最后排查发现是打包的时候jdk使用了1.8版本
而现场环境是1.7版本，也是一起活生生的血泪史啊！！！
在此与大家共勉，也给大家提供大神的排查思路