前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MySQL单表模拟锁和事务的几个场景

MySQL单表模拟锁和事务的几个场景

作者头像
jeanron100
发布2018-03-21 17:33:43
2.7K0
发布2018-03-21 17:33:43
举报
文章被收录于专栏:杨建荣的学习笔记

在MySQL中对于并发,锁问题总是会有很多值得讨论的地方,但是通常来说,要模拟这些锁或者一些锁的问题需要花点功夫,比如创建多个表,创建大量的数据,然后像调试钟表的秒针一样,让问题刚好复现在哪个时间点上。如果换一个角度,单表来模拟这类而是可以吗,其实是可行的。

今天简单通过单表的测试模拟死锁,事务中的隐式提交(其实可以理解是个bug),间歇锁。

初始化数据

首先的准备工作就是初始化数据,我们创建一个表test,事务隔离级别为默认的RR。

建表语句:

create table test(

id int not null ,

name int ,

primary key(id),

unique key(name)

) engine=innodb;

事务隔离级别:

mysql> show variables like '%isolation%';

+---------------+-----------------+

| Variable_name | Value |

+---------------+-----------------+

| tx_isolation | REPEATABLE-READ |

+---------------+-----------------+

1 row in set (0.00 sec)

除此之外就是打开两个窗口,我们简称为会话1,会话2.

模拟死锁

我们开始先模拟一下死锁问题。

会话1:

我们开启一个事务,插入一行记录,数据就选做今天的日期吧。

mysql>begin;

mysql> insert into test values(2017,827);

Query OK, 1 row affected (0.01 sec)

会话2;

mysql> insert into test values(2016,827);

这个时候会话2会阻塞,这个时候有一种特殊的情况,那就是阻塞超时,如果超时,会自动停止。

会话1:

mysql> insert into test values(2018,826);

Query OK, 1 row affected (0.00 sec)

可见会话1中的DML操作依旧是可以的。

会话2:

mysql> insert into test values(2016,827);

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

如果看会话2的情况,就会发现产生了死锁。

如果要尝试事务隔离级别RC,其实表现的效果是一样的。

仔细看看这个操作的过程就会发现,还是蛮“奇怪”的,数据之间彼此没有直接的依赖关联,怎么会产生死锁,这个里面有银式锁升级,还有间歇锁的一些东西,留给大家思考吧。

模拟意料之外的事务自动提交

为了基于上面的测试数据,让两条数据成功插入,我们在会话2中结束事务。

mysql>commit;

然后开始做意料之外的事务自动提交测试,这一次我们在同一个会话中测试即可。问题的背景是如果我们显式声明事务,在同一会话中做了DML操作,没有提交,如果再开启一个事务,之前的事务会自动提交。

会话1:

这是基于场景1的测试之后的数据情况。

mysql> select *from test;

+------+------+

| id | name |

+------+------+

| 2018 | 826 |

| 2017 | 827 |

+------+------+

2 rows in set (0.00 sec)

我们显式声明一个事务。

mysql> begin;

Query OK, 0 rows affected (0.02 sec)

然后插入一条记录,重新给一个日期。

mysql> insert into test values(2019,825);

Query OK, 1 row affected (0.00 sec)

这个时候没有提交,我们在当前会话中重新再开启一个事务。

mysql > begin;

mysql > insert into test values(2015,830);

这个时候如果在会话2中查看,其实会发现,事务已经帮你提交了。

mysql> select *from test;

+------+------+

| id | name |

+------+------+

| 2018 | 826 |

| 2017 | 827 |

+------+------+

2 rows in set (0.00 sec)

在会话1我们继续回滚事务,会发现于事无补。

mysql> rollback;

Query OK, 0 rows affected (0.01 sec)

这个时候数据已经自动提交了一部分。

mysql> select *from test;

+------+------+

| id | name |

+------+------+

| 2018 | 826 |

| 2017 | 827 |

+------+------+

2 rows in set (0.00 sec)

间歇锁测试

上面的测试场景其实还是多多少少都有些关联,其中第一个场景和间歇锁也有关系,我就简单用单表模拟一下间歇锁。

首先还是保证事务隔离级别是RR,因为间歇锁是RR隔离级别特供,RC中就没有间歇锁这样的定制,在并发场景中还是有不小的影响。我们来看看效果。

会话1:

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

指定数据范围,然后显示声明。

mysql> select id from test where id <2019 lock in share mode;

+------+

| id |

+------+

| 2018 |

| 2017 |

+------+

2 rows in set (0.00 sec)

会话2:

会话2中也开启一个事务,插入一条记录。结果就被阻塞了。

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

mysql> insert into test values(2016,829);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

直到事务超时才作罢。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-08-27,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL(TencentDB for MySQL)为用户提供安全可靠,性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性,包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL,可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理,不仅经济实惠,而且稳定可靠,易于运维。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档