MySQL单表模拟锁的几个场景

  在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

直到事务超时才作罢。

 

时间: 2024-10-09 08:31:20

MySQL单表模拟锁的几个场景的相关文章

RDS for MySQL InnoDB 表级锁等待

RDS for MySQL InnoDB 表级锁等待   1. 显式 lock table 2. 隐式 lock table 在 RDS MySQL 实例日常使用中,有些情况下会发现出现 InnoDB 表级锁等待的情况,下面列出常见的2个原因.  1. 显式 lock table 执行了 lock tables tab_name read; 导致 DML 会话等待在表的表级锁上. 会话 1 lock tables tab_name read; 会话 2 会话 3   2. 隐式 lock tab

MySQL单表多关键字模糊查询的实现方法_Mysql

在最近的一个项目需要实现在MySQL单表多关键字模糊查询,但这数个关键字并不一定都存在于某个字段.例如现有table表,其中有title,tag,description三个字段,分别记录一条资料的标题,标签和介绍.然后根据用户输入的查询请求,将输入的字串通过空格分割为多个关键字,再在这三个字段中查询包含这些关键字的记录. 可目前遇到的问题是,这些关键字是可能存在于三个字段中的任意一个或者多个,但又要求三个字段必须包含所有的关键词.如果分别对每个字段进行模糊匹配,是没法实现所需的要求,由此想到两种

mysql单表多timestamp报错#1293 - Incorrect table definition;

mysql单表多timestamp报错#1293 - Incorrect table definition; there can be only one TIMESTAMP column with C解决 一个表中出现多个timestamp并设置其中一个为current_timestamp的时候经常会遇到 #1293 - Incorrect table definition; there can be only oneTIMESTAMP column with CURRENT_TIMESTAMP

MySQL单表ibd文件恢复方法详解_Mysql

前言: 随着innodb的普及,innobackup也成为了主流备份方式.物理备份对于新建slave,全库恢复的需求都能从容应对. 但当面临单表数据误删,或者单表误drop的情况,如果使用物理全备进行恢复呢? 下文将进行详细分析. 恢复过程中需要用到的工具,percona data recover tool : https://launchpad.net/percona-innodb-recovery-tool 情况一:误删部分数据,需要用最近一次备份覆盖 来自同一台机器的ibd恢复覆盖,且备份

MySQL单表百万数据记录分页性能优化技巧_Mysql

测试环境: 先让我们熟悉下基本的sql语句,来查看下我们将要测试表的基本信息 use infomation_schema SELECT * FROM TABLES WHERE TABLE_SCHEMA = 'dbname' AND TABLE_NAME = 'product' 查询结果: 从上图中我们可以看到表的基本信息: 表行数:866633 平均每行的数据长度:5133字节 单表大小:4448700632字节 关于行和表大小的单位都是字节,我们经过计算可以知道 平均行长度:大约5k 单表总大

mysql单表体积和一个库设计多少张表为妥

这篇文章来自于看博客园一个园友的分享经历,原文:http://www.cnblogs.com/qqloving/p/3427138.html   他不清楚mysql一个库里面分多少张表合适,他一个库分了8000张表.于是我看了,忍不住作答.   于是以个人随笔的形式给自己做知识备忘吧.   1.单表体积多大的时候需要分表   曾经看过一个博客,分析到什么情况下需要分表. 单表形式访问(也就是对这个表的访问不涉及到join联合查询):单个表的体积大于2g的时候.或者说,单个表的行数达到一千万的时候

mysql单表多timestamp的current_timestamp设置问题

一个表中出现多个timestamp并设置其中一个为current_timestamp的时候经常会遇到 1293 - Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause 原因是当你给一个timestamp设置为on update current_timestamp的时候,其他的timestamp字段需要显式设定

MYSQL MyISAM表锁

锁是计算机协调多个进程或线程并发访问某一资源的机制 .在数据库中,除传统的 计算资源(如CPU.RAM.I/O等)的争用以外,数据也是一种供许多用户共享的资源.如何保证数据并发访问的一致性.有效性是所有数据库必须解决的一 个问题,锁冲突也是影响数据库并发访问性能的一个重要因素. 从这个角度来说,锁对数据库而言显得尤其重要,也更加复杂.本章我们着重讨论MySQL锁机制 的特点,常见的锁问题,以及解决MySQL锁问题的一些方法或建议. MySQL锁概述 相对其他数据库而言,MySQL的锁机制比较简单

【重磅推荐】MySQL大表优化方案(最全面)

当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的.而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量: 字段 尽量使用TINYINT.SMALLINT.MEDIUM_INT作为整数类型而非INT,如果非负则加上UNSIGNED VARCHAR的