由于每天起的太早，所以中午必须要午休，否则无法保证下午的工作状态。正在午休时，电话响起，一阵急促的声音，“看看咱们的message 系统，短信发不出去了，经销商无法登陆 ACS 系统了。“已经有客户 complain了。

问题的马上解决，要不被投诉可不是好玩的。本来这个系统已经重新设计，并且老的MYSQL server也处于要被 dump的状态。并且近很忙，根本没有时间管这个“可有可无” 的系统。事情都是这样，你越觉得他可有可无，他在“临终” 一定要给你闹点脾气。

马上登上系统，内存已经溢出了，（怎么看内存溢出，和MYSQL 无关，和LINUX 有关，这里我也不是那什么，仅仅是会看，具体还是请LINUX 高手来吧）。然后进入到MYSQL系统里面，查看，发现有死锁。

其实还有很多，这里就截屏一个。

早就知道这个系统，几经易手里面的表设计，就不多说了，出现这样的问题是很正常的。在查看系统的的 MY.CNF 配置，里面的 isolation 是 repeatable-read ，其实本来就算设置成 repeatable-read MYSQL 系统不会出现问题，而可怕的问题就出在，系统的要求隔离级别不低，而系统弄的设计很低，如同25年前经常听到的，社会生产资料和人们大众的需求严重不匹配这样的“题”。

本来已经在重新设计系统了，当前系统是不可能进行更改任何设置了，就让他继续工作好了， 夕阳已经不远了，浪费过多的精力是没有必要，如果想知道 为什么  repeatable -read 会产生更多的锁，可以找找我之前写的关于gap 锁的一篇文章。相对 read-commit  ,repeatable -read 会产生更多的间隙锁，造成更多的死锁。

那问题就很清楚了，怎么处理也很清楚

1  开发不会更改任何东西

2  继续要工作

回答也很简单

1 内存溢出，加内存

2 设计有问题，经常锁，（找出慢语句，加索引），（降低isolation）

3 适当的添加 change buffer

需求很明确，剩下的就是干活。

经过10分钟的修改，add memory , restart

系统恢复上线，至少我到现在没有在接到“火上房”的电话。

当然这没有完，自己反思一下，如果遇到这样的问题怎么办

首先监控上存在问题，死锁时没有报警的，MYSQL 数据库的死锁和其他的数据库不是太一样，因为MYSQL 在设计之初都会尽力避免这样的事情发生，所以在一个良好的系统中，死锁一般很少发生。所以后期在设计之初的要求，和后期的监控上，要做的工作还很漫长。