[背景简介]

MySQL是一种开放源代码的关系型数据库管理系统(RDBMS)，因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下，MySQL是管理内容最好的选择。mysql虽然功能未必很强大，但因为它的开源、广泛传播，导致很多人都了解到这个数据库。故障基本都能通过社区和官方文档获取解决方案，在应用范围上也是很广的，互联网公司基本都有使用mysql。本章主要针对mysql5.7.25的锁表故障进行分析处理。

[分析过程]

1、首先接到业务反馈数据库完全无法写入数据了，后查看数据库监控发现指标正常；

2、登陆数据库主机核实主机资源正常：

3、通过showprocesslist查看当前连接，发现300左右的连接基本全是waitingfor global read lock和少部分waitingfor stored function metadata lock以及FLUSHTABLES WITH READ LOCK，如下所示

4、通过showOPEN TABLES where In_use > 0查看当前被锁表xx_test，

5、通过查看当前事务发现只有两个事务；

6、通过查看当前正在锁事务和等待锁事务，发现并没有记录有正在锁事务和等待锁事务

7、通过查看当前事务确认到目前只有两个事务在运行，其它都是都在等待，且无等待锁表及正在锁表。

8、发现备份账号FLUSHTABLES WITH READ LOCK关闭所有打开的表并使用全局读锁锁定所有数据库的所有表，所以业务查询没有问题。

9、猜想应该是因为xx_test的锁表阻塞了FLUSHTABLES WITH READ LOCK执行，导致整个数据库完全无法修改。

[验证过程]

1. 首先通过processlist输出看到锁表xx_test连接有3个等待该表的锁，其它并没有该表请求连接，先将这三个等待的select连接kill。

2. 然后将当前正在执行的两个事务kill。

3. 观察数据库发现FLUSH TABLES WITH READ LOCK结束，其它等待事务都开始执行，数据库恢复正常。

[总结]

数据库触发FLUSHTABLES WITH READLOCK应该是有业务方在备份，单纯的表被锁了一般情况下也只会影响锁表的写，但是在锁表情况的备份触发FLUSHTABLES WITH READ LOCK，就可能导致整个库变成只读，建议备份工作都放在晚上闲时。