记一次数据库踩下的坑

一、缘起

　　公司部署了一套系统，之前在别的地方部署没有问题，运行正常，但是在济南部署时就出现了问题

　　出现的问题是：错误日志信息不能插入错误信息的日志表中，导致前台查不到错误信息数据

 

二、排查

　　（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版本，也是一起活生生的血泪史啊！！！

　　　　  在此与大家共勉，也给大家提供大神的排查思路