MySQL 常见故障以及诊断和解决方案

此篇是我在生产环境中遇到 MySQL 的一些问题的总结和思考，希望能够帮助更多的人快速定位和解决线上生产环境中遇到的问题。

慢查询太多导致整个库性能下降

这是最常见的一个问题，尤其是在团队开发人员水平参差不齐，对 MySQL 的使用不规范，SQL 语句在代码中乱飞，缺乏严格约束和检验时很容易写出在某些情况下演变成灾难性质的慢查询。

问题现象

• 应用程序卡顿
• 如果设置了最大连接数，可能会报超过最大连接数限制
• 应用服务器请求堆积，造成大量的 TIME_WAIT
• 单位时间内慢查询明显增多
• 服务器的连接数比平时正常流量时增多

解决方案

1. 查看所有慢查询语句占用的线程，找到然后 kill 掉

select id,';' from `information_schema`.PROCESSLIST where info like '%table_name%';

1. 尽快禁止业务代码中的慢查询

可以考虑暂时屏蔽相关的功能或暂时下掉相关的业务，并重启服务

1. 检查导致慢查询的原因

慢查询有很多原因会导致，比如更新数据太多，时间太长，没有合理使用索引，表太大等等，要根据的自己的业务情况进行分析和解决

主从同步不一致

造成主从不同步的原因有很多，简单列举几个可能的原因：

• 无意中在从库开启了写权限，导致一些数据进入了从库
• 网络故障导致从库不能更新主库的数据，网络再次恢复时主从延迟太大
• 其他原因

问题现象

从库的数据和主库不一致

解决方案

解决主从不一致的一种最好的办法是暂时先下掉从库，并从某一时间点恢复从库，然后再接入主库进行更新。这里有一个问题是暂时下掉从节点会导致其他节点压力骤增，从而导致整个服务有可能崩溃的风险，为了防止这样的问题出现，在设计数据库架构之初就要考虑预留一定的量来处理某个节点故障的问题。

在线对大表进行 DDL 导致表锁死

更改表结构在业务不稳定时进行的非常频繁，但是对 online 表结构进行变更要非常小心谨慎，尤其是表的数据量比较大，业务比较复杂，即可能导致业务功能无法使用等严重现象，一般来说超过百万以上的数据都要小心进行表结构变更。

问题现象

在线变更表结构导致使用该表的业务假死

alter table add colum1 string not null default '';

解决方案

• 如果数据量比较小（百万以下），数据变更不频繁，可以直接变更
• 大表可以考虑采用成熟的开源解决方案，详见mysql 在线 scheme 变更方案以及