并发场景下MySQL存在的问题及解决思路
转载自 并发场景下MySQL存在的问题及解决思路
目录
1、背景
2、表锁导致的慢查询的问题
3、线上修改表结构有哪些风险？
4、一个死锁问题的分析
5、锁等待问题的分析
6、小结
一、背景
对于数据库系统来说在多用户并发条件下提高并发性的同时又要保证数据的一致性一直是数据库系统追求的目标，既要满足大量并发访问的需求又必须保证在此条件下数据的安全，为了满足这一目标大多数数据库通过锁和事务机制来实现，MySQL数据库也不例外。尽管如此我们仍然会在业务开发过程中遇到各种各样的疑难问题，本文将以案例的方式演示常见的并发问题并分析解决思路。
二、表锁导致的慢查询问题
首先我们看一个简单案例，根据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存储引擎，减少写操作的时间；
三、线上修改表结构有哪些问题
如果有一天业务系统需要增大一个字段长度，能否在线上直接修改呢？在回答这个问题前，我们先来看一个案例：
以上语句尝试修改user表的name字段长度，语句被阻塞。按照惯例，我们检查一下当前进程：
从进程可以看出alter语句在等待一个元数据锁，而这个元数据锁很可能是上面这条select语句引起的，事实正是如此。在执行DML（select、update、delete、insert）操作时，会对表增加一个元数据锁，这个元数据锁是为了保证在查询期间表结构不会被修改，因此上面的alter语句会被阻塞。那么如果执行顺序相反，先执行alter语句，再执行DML语句呢？DML语句会被阻塞吗？例如我正在线上环境修改表结构，线上的DML语句会被阻塞吗？答案是：不确定。
在MySQL5.6开始提供了online ddl功能，允许一些DDL语句和DML语句并发，在当前5.7版本对online ddl又有了增强，这使得大部分DDL操作可以在线进行。详见：https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html
所以对于特定场景执行DDL过程中，DML是否会被阻塞需要视场景而定。
总结：
通过这个例子我们对元数据锁和online ddl有了一个基本的认识，如果我们在业务开发过程中有在线修改表结构的需求，可以参考以下方案：
1、尽量在业务量小的时间段进行；
2、查看官方文档，确认要做的表修改可以和DML并发，不会阻塞线上业务；
3、推荐使用percona公司的pt-online-schema-change工具，该工具被官方的online ddl更为强大，它的基本原理是：通过insert… select…语句进行一次全量拷贝，通过触发器记录表结构变更过程中产生的增量，从而达到表结构变更的目的。
例如要对A表进行变更，主要步骤为：
创建目的表结构的空表，A_new;
在A表上创建触发器，包括增、删、改触发器;
通过insert…select…limit N 语句分片拷贝数据到目的表
Copy完成后，将A_new表rename到A表。
四、一个死锁问题的分析
在线上环境下死锁的问题偶有发生，死锁是因为两个或多个事务相互等待对方释放锁，导致事务永远无法终止的情况。为了分析问题，我们下面将模拟一个简单死锁的情况，然后从中总结出一些分析思路。
演示环境：MySQL5.7.20 事务隔离级别：RR
表user：
|
CREATE TABLE `user` ( |
|---|
下面演示事务1、事务2工作的情况：
|
事务1 |
事务2 |
事务监控 |
|
|---|---|---|---|
| T1 |
begin; Query OK, 0 rows affected (0.00 sec) |
begin; Query OK, 0 |
|
| T2 |
select * from user where id=3 for update; +----+------+------+ |
select * from user where id=4 for update; +----+------+------+ |
select * from information_ schema.INNODB_TRX； 通过查询元数据库innodb事务表，监控到当前运行事务数为2，即事务1、事务2。 |
| T3 |
update user set name='haha' where id=4; 因为id=4的记录已被事务2加上行锁，该语句将阻塞 |
监控到当前运行事务数为2。 | |
| T4 | 阻塞状态 |
update user set name='hehe' where id=3; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction id=3的记录已被事务1加上行锁，而本事务持有id=4的记录行锁，此时InnoDB存储引擎检查出死锁，本事务被回滚。 |
事务2被回滚，事务1仍在运行中，监控当前运行事务数为1。 |
| T5 |
Query OK, 1 row affected (20.91 sec) 由于事务2被回滚，原来阻塞的update语句被继续执行。 |
监控当前运行事务数为1。 | |
| T6 |
commit； Query OK, 0 rows affected (0.00 sec) |
事务1已提交、事务2已回滚，监控当前运行事务数为0。 |
这是一个简单的死锁场景，事务1、事务2彼此等待对方释放锁，InnoDB存储引擎检测到死锁发生，让事务2回滚，这使得事务1不再等待事务B的锁，从而能够继续执行。那么InnoDB存储引擎是如何检测到死锁的呢？为了弄明白这个问题，我们先检查此时InnoDB的状态：
show engine innodb status\G
------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-01-14 12:17:13 0x70000f1cc000
*** (1) TRANSACTION:
TRANSACTION 5120, ACTIVE 17 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 10, OS thread handle 123145556967424, query id 2764 localhost root updating
update user set name='haha' where id=4
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 94 page no 3 n bits 80 index PRIMARY of table `test`.`user` trx id 5120 lock_mode X locks rec but not gap waiting
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000004; asc ;;
1: len 6; hex 0000000013fa; asc ;;
2: len 7; hex 520000060129a6; asc R ) ;;
3: len 4; hex 68616861; asc haha;;
4: len 4; hex 80000015; asc ;;
*** (2) TRANSACTION:
TRANSACTION 5121, ACTIVE 12 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 11, OS thread handle 123145555853312, query id 2765 localhost root updating
update user set name='hehe' where id=3
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 94 page no 3 n bits 80 index PRIMARY of table `test`.`user` trx id 5121 lock_mode X locks rec but not gap
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000004; asc ;;
1: len 6; hex 0000000013fa; asc ;;
2: len 7; hex 520000060129a6; asc R ) ;;
3: len 4; hex 68616861; asc haha;;
4: len 4; hex 80000015; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 94 page no 3 n bits 80 index PRIMARY of table `test`.`user` trx id 5121 lock_mode X locks rec but not gap waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000003; asc ;;
1: len 6; hex 0000000013fe; asc ;;
2: len 7; hex 5500000156012f; asc U V /;;
3: len 4; hex 68656865; asc hehe;;
4: len 4; hex 80000014; asc ;;
*** WE ROLL BACK TRANSACTION (2)
InnoDB状态有很多指标，这里我们截取死锁相关的信息，可以看出InnoDB可以输出最近出现的死锁信息，其实很多死锁监控工具也是基于此功能开发的。
在死锁信息中，显示了两个事务等待锁的相关信息（蓝色代表事务1、绿色代表事务2），重点关注：WAITING FOR THIS LOCK TO BE GRANTED和HOLDS THE LOCK(S)。
WAITING FOR THIS LOCK TO BE GRANTED表示当前事务正在等待的锁信息，从输出结果看出事务1正在等待heap no为5的行锁，事务2正在等待 heap no为7的行锁；
HOLDS THE LOCK(S)：表示当前事务持有的锁信息，从输出结果看出事务2持有heap no为5行锁。
从输出结果看出，最后InnoDB回滚了事务2。
那么InnoDB是如何检查出死锁的呢？
我们想到最简单方法是假如一个事务正在等待一个锁，如果等待时间超过了设定的阈值，那么该事务操作失败，这就避免了多个事务彼此长等待的情况。参数innodb_lock_wait_timeout正是用来设置这个锁等待时间的。
如果按照这个方法，解决死锁是需要时间的（即等待超过innodb_lock_wait_timeout设定的阈值），这种方法稍显被动而且影响系统性能，InnoDB存储引擎提供一个更好的算法来解决死锁问题，wait-for graph算法。简单的说，当出现多个事务开始彼此等待时，启用wait-for graph算法，该算法判定为死锁后立即回滚其中一个事务，死锁被解除。该方法的好处是：检查更为主动，等待时间短。
下面是wait-for graph算法的基本原理：
为了便于理解，我们把死锁看做4辆车彼此阻塞的场景：
4辆车看做4个事务，彼此等待对方的锁，造成死锁。wait-for graph算法原理是把事务作为节点，事务之间的锁等待关系，用有向边表示，例如事务A等待事务B的锁，就从节点A画一条有向边到节点B，这样如果A、B、C、D构成的有向图，形成了环，则判断为死锁。这就是wait-for graph算法的基本原理。
总结：
1、如果我们业务开发中出现死锁如何检查出？刚才已经介绍了通过监控InnoDB状态可以得出，你可以做一个小工具把死锁的记录收集起来，便于事后查看。
2、如果出现死锁，业务系统应该如何应对？从上文我们可以看到当InnoDB检查出死锁后，对客户端报出一个Deadlock found when trying to get lock; try restarting transaction信息，并且回滚该事务，应用端需要针对该信息，做事务重启的工作，并保存现场日志事后做进一步分析，避免下次死锁的产生。
五、锁等待问题的分析
在业务开发中死锁的出现概率较小，但锁等待出现的概率较大，锁等待是因为一个事务长时间占用锁资源，而其他事务一直等待前个事务释放锁。
|
事务1 |
事务2 |
事务监控 |
|
|---|---|---|---|
| T1 |
begin; Query OK, 0 rows affected (0.00 sec) |
begin; Query OK, 0 rows affected (0.00 sec) |
|
| T2 |
select * from user where id=3 for update; +----+------+------+ |
其他查询操作 |
select * from information_schema.INNODB_TRX； 通过查询元数据库innodb事务表，监控到当前运行事务数为2，即事务1、事务2。 |
| T3 | 其他查询操作 |
update user set name='hehe' where id=3; 因为id=3的记录被事务1加上行锁，所以该语句将阻塞（即锁等待） |
监控到当前运行事务数为2。 |
| T4 | 其他查询操作 |
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 锁等待时间超过阈值，操作失败。注意：此时事务2并没有回滚。 |
监控到当前运行事务数为2。 |
| T5 | commit; | 事务1已提交，事务2未提交，监控到当前运行事务数为1。 |
从上述可知事务1长时间持有id=3的行锁，事务2产生锁等待，等待时间超过innodb_lock_wait_timeout后操作中断，但事务并没有回滚。如果我们业务开发中遇到锁等待，不仅会影响性能，还会给你的业务流程提出挑战，因为你的业务端需要对锁等待的情况做适应的逻辑处理，是重试操作还是回滚事务。
在MySQL元数据表中有对事务、锁等待的信息进行收集，例如information_schema数据库下的INNODB_LOCKS、INNODB_TRX、INNODB_LOCK_WAITS，你可以通过这些表观察你的业务系统锁等待的情况。你也可以用一下语句方便的查询事务和锁等待的关联关系：
| SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query wating_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM information_schema.innodb_lock_waits w INNER JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id INNER JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id; |
|---|
结果：
waiting_trx_id: 5132
waiting_thread: 11
wating_query: update user set name='hehe' where id=3
blocking_trx_id: 5133
blocking_thread: 10
blocking_query: NULL
总结：
1、请对你的业务系统做锁等待的监控，这有助于你了解当前数据库锁情况，以及为你优化业务程序提供帮助；
2、业务系统中应该对锁等待超时的情况做合适的逻辑判断。
六、小结
本文通过几个简单的示例介绍了我们常用的几种MySQL并发问题，并尝试得出针对这些问题我们排查的思路。文中涉及事务、表锁、元数据锁、行锁，但引起并发问题的远远不止这些，例如还有事务隔离级别、GAP锁等。真实的并发问题可能多而复杂，但排查思路和方法却是可以复用，在本文中我们使用了show processlist;show engine innodb status;以及查询元数据表的方法来排查发现问题，如果问题涉及到了复制，还需要借助master/slave监控来协助。
并发场景下MySQL存在的问题及解决思路相关推荐
- 分布式锁和mysql事物扣库存_这个是真的厉害，高并发场景下的订单和库存处理方案，讲的很详细了！...
前言 之前一直有小伙伴私信我问我高并发场景下的订单和库存处理方案,我最近也是因为加班的原因比较忙,就一直没来得及回复.今天好不容易闲了下来想了想不如写篇文章把这些都列出来的,让大家都能学习到,说一千道 ...
- MySQL在并发场景下的问题及解决思路
MySQL在并发场景下的问题及解决思路 参考文章: (1)MySQL在并发场景下的问题及解决思路 (2)https://www.cnblogs.com/leefreeman/p/8286550.htm ...
- 高并发场景下数据库的常见问题及解决方案
一.分库分表 (1)为什么要分库分表 随着系统访问量的增加,QPS越来越高,数据库磁盘容量不断增加,一般数据库服务器的QPS在800-1200的时候性能最佳,当超过2000的时候sql就会变得很慢并且 ...
- 读数据库遇到空就进行不下去_如何解决高并发场景下缓存+数据库双写不一致问题?...
推荐阅读: 一只Tom猫:手撕分布式技术:限流.通讯.缓存,全部一锅端走送给你!zhuanlan.zhihu.com 一只Tom猫:MySQL复习:20道常见面试题(含答案)+21条MySQL性能调 ...
- java分布式库存系统_这个是真的厉害，高并发场景下的订单和库存处理方案，讲的很详细了！...
前言 之前一直有小伙伴私信我问我高并发场景下的订单和库存处理方案,我最近也是因为加班的原因比较忙,就一直没来得及回复.今天好不容易闲了下来想了想不如写篇文章把这些都列出来的,让大家都能学习到,说一千道 ...
- 华为云：如何解除数据库高并发场景下的达摩克利斯之剑？
5月10-12日,第九届中国数据库技术大会(DTCC 2018)如约而至.大会邀请了百余位行业专家,就数据库.大数据等热点技术话题进行分享.其中,华为云数据库首席架构师 带来的主题演讲<MySQ ...
- 关于std::string 在 并发场景下 __grow_by_and_replace free was not allocated 的异常问题
使用string时发现了一些坑. 我们知道stl 容器并不是线程安全的,所以在使用它们的过程中往往需要一些同步机制来保证并发场景下的同步更新. 应该踩的坑还是一个不拉的踩了进去,所以还是记录一下吧. ...
- 高并发场景下，到底先更新缓存还是先更新数据库？
在大型系统中,为了减少数据库压力通常会引入缓存机制,一旦引入缓存又很容易造成缓存和数据库数据不一致,导致用户看到的是旧数据. 为了减少数据不一致的情况,更新缓存和数据库的机制显得尤为重要,接下来带领大 ...
- 高并发场景下缓存的常见问题
作者介绍: 丁浪,非著名架构师.关注高并发.高可用的架构设计,对系统服务化.分库分表.性能调优等方面有深入研究和丰富实践经验.热衷于技术研究和分享. 声明:版权归丁浪作者本人所有,转载请联系作者本人 ...
最新文章
- 青源 LIVE 预告 | 复旦大学：NLP 的范式迁移
- 转VS2010解决方案转换到VS2008
- C语言程序设计输入x求函数y,C语言程序设计实践（OJ）-初识函数
- 第一次接触AgilePoint业务流程及任务管理（BPM）
- 【ML】 李宏毅机器学习二：Logistic Regression
- [蓝桥杯2018初赛]第几个幸运数-数论+枚举
- 图解 CSS (1): 先做一个样式表测试工具
- 项目背景怎么描述_培训回顾 |第六届“互联网+”之创业大赛项目计划书撰写
- 计算机分子模拟聚乙烯,分子动力学模拟超高分子量聚乙烯
- Android倒计时工具
- OSI七层模型与TCP/IP四层与五层模型详解
- 基于python使用CV裁剪图片
- 想把语音转成文字，就这样做
- 但管努力，莫问前程，事在人为，功不唐捐
- 【数据库架构】NewSQL和PGXC
- 【精品】防止表单重复提交 方法汇总
- 夺宝奇兵 （优先队列 + 贪心 + 暴力枚举）
- java uuid去掉横线_UUID去横杠-的正确方式
- “以简驭繁”打造卓越校园网 ——锐捷助力西安理工大学校园网建设
- STM32 PWM的理解