MySQL在并发场景下的问题及解决思路

目录

    1、背景

    2、表锁导致的慢查询的问题

    3、线上修改表结构有哪些风险？

    4、一个死锁问题的分析

    5、锁等待问题的分析

    6、小结

1、背景

    对于数据库系统来说在多用户并发条件下提高并发性的同时又要保证数据的一致性一直是数据库系统追求的目标，既要满足大量并发访问的需求又必须保证在此条件下数据的安全，为了满足这一目标大多数数据库通过锁和事务机制来实现，MySQL数据库也不例外。尽管如此我们仍然会在业务开发过程中遇到各种各样的疑难问题，本文将以案例的方式演示常见的并发问题并分析解决思路。

2、表锁导致的慢查询的问题

首先我们看一个简单案例，根据ID查询一条用户信息：

mysql> select * from user where id=6;

这个表的记录总数为3条，但却执行了13秒。

出现这种问题我们首先想到的是看看当前MySQL进程状态：

从进程上可以看出select语句是在等待一个表锁，那么这个表锁又是什么查询产生的呢？这个结果中并没有显示直接的关联关系，但我们可以推测多半是那条update语句产生的（因为进程中没有其他可疑的SQL），为了印证我们的猜测，先检查一下user表结构：

果然user表使用了MyISAM存储引擎，MyISAM在执行操作前会产生表锁，操作完成再自动解锁。如果操作是写操作，则表锁类型为写锁，如果操作是读操作则表锁类型为读锁。正如和你理解的一样写锁将阻塞其他操作(包括读和写)，这使得所有操作变为串行；而读锁情况下读-读操作可以并行，但读-写操作仍然是串行。以下示例演示了显式指定了表锁（读锁），读-读并行，读-写串行的情况。

显式开启/关闭表锁，使用lock table user read/write; unlock tables;

session1:

session2：

可以看到会话1启用表锁（读锁）执行读操作，这时会话2可以并行执行读操作，但写操作被阻塞。接着看：

session1:

session2:

当session1执行解锁后，seesion2则立刻开始执行写操作，即读-写串行。

总结：

到此我们把问题的原因基本分析清楚，总结一下——MyISAM存储引擎执行操作时会产生表锁，将影响其他用户对该表的操作，如果表锁是写锁，则会导致其他用户操作串行，如果是读锁则其他用户的读操作可以并行。所以有时我们遇到某个简单的查询花了很长时间，看看是不是这种情况。

解决办法：

1）、尽量不用MyISAM存储引擎，在MySQL8.0版本中已经去掉了所有的MyISAM存储引擎的表，推荐使用InnoDB存储引擎。

2）、如果一定要用MyISAM存储引擎，减少写操作的时间；

3、线上修改表结构有哪些风险？

如果有一天业务系统需要增大一个字段长度，能否在线上直接修改呢？在回答这个问题前，我们先来看一个案例：