mysql bug 77209_MySQL 锁问题最佳实践

最近一段时间处理了较多锁的问题，包括锁等待导致业务连接堆积或超时，死锁导致业务失败等，这类问题对业务可能会造成严重的影响，没有处理经验的用户往往无从下手。下面将从整个数据库设计，开发，运维阶段介绍如何避免锁问题的发生，提供一些最佳实践供RDS的用户参考。

在数据库设计阶段，引擎选择和索引设计不当可能导致后期业务上线后出现较为严重的锁或者死锁问题。

1. 表引擎选择使用myisam，引发table level lock wait。

从5.5版本开始，MySQL官方就把默认引擎由myisam转为innodb，这两种引擎的主要区别：

由于myisam引擎只支持table lock，在使用myisam引擎表过程中，当数据库中出现执行时间较长的查询后就会堵塞该表上的更新动作，所以经常会碰到线程会话处于表级锁等待(Waiting for table level lock)的情况，严重的情况下会出现由于实例连接数被占满而应用无法正常连接的情况

从上述的案例中可以看到，t_myisam表为myisam存储引擎，当该表上有执行时间较长的查询语句在执行的时候，该表上其他的更新全被堵塞住了，这个时候应用或者数据库的连接很快耗完，导致应用请求失败。这个时候快速的恢复方法为将线程id：111 kill掉即可(可以执行show processlist查看到当前数据库所有连接状态)。另外myisam存储引擎的表索引在实例异常关闭的情况下会导致索引损坏，这个时候必须要对表进行repair操作，该操作同样会阻塞该表上的所有请求。

2. 表索引设计不当，导致数据库出现死锁。

索引设计是数据库设计非常重要的一环，不仅仅关系到后续业务的性能，如果设计不当还可导致业务上的死锁。下面的一则案例就出现在线上系统，数据库在并发更新的时候出现了死锁，通过排查定位于update更新使用了两个索引导致，死锁信息如下：

表结构：

SQL执行计划：

所以第一个事务先根据group_id索引，已经锁住primary id，然后再根据test_id索引，锁定primary id；第二个事务先根据test_id索引，已经锁住primary id，然后再根据group_id索引，去锁primary id；所以这样并发更新就可能出现死索引。

MySQL官方也已经确认了此bug：77209，解决方法有两种：

事务处理时间过长，导致并发出现锁等待。

并发事务处理在数据库中经常看到的应用场景，在这种场景下，需要避免大事务，长事务，复杂事务导致事务在数据库中的运行时间加长，事务时间变长则导致事务中锁的持有时间变长，影响整体的数据库吞吐量。下面的一则案例中，用户的业务数据库中出现大量的update等待，导致大量的业务超时报错：

问题排查：

DDL操作被大查询block。

当应用上线进入维护阶段，则开始会有较多的数据库变更操作，比如：添加字段，添加索引等操作，这一类操作导致的锁故障也是非常频繁的，下面将会介绍一则案例，一个DDL操作被查询block，导致数据库连接堆积：

Metadata lock wait 的含义：为了在并发环境下维护表元数据的数据一致性，在表上有活动事务(显式或隐式)的时候，不可以对元数据进行写入操作。因此 MySQL 引入了 metadata lock ，来保护表的元数据信息。因此在对表进行上述操作时，如果表上有活动事务(未提交或回滚)，请求写入的会话会等待在 Metadata lock wait。

导致 Metadata lock wait 等待的常见因素包括：活动事务，当前有对表的长时间查询，显示或者隐式开启事务后未提交或回滚，比如查询完成后未提交或者回滚，表上有失败的查询事务等。

上述案例中，查询，更新和DDL操作的线程状态都为Waiting for table metadata lock，对表t的操作全部被阻塞，前端源源不断的请求到达数据库，这个时候数据库的连接很容易被打满，那我们来分析一下为什么有这这些锁等待：

解决办法则是将线程6 kill 掉即可。

锁问题是非常常见的问题，需要我们在数据库开发、设计、管理的各个阶段都需要注意，防范未然，做到心中有数。

设计开发阶段:

管理运维阶段：