【MySQL】事务?隔离级别?锁?详解MySQL并发控制机制

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用版 2核4GB 50GB
简介: 【MySQL】事务?隔离级别?锁?详解MySQL并发控制机制

1.先理清一下概念

所谓并发控制指的是在对数据库进行并发操作时如何保证数据的一致性和正确性。在数据库中与并发控制相关的概念有如下几个:

  • 事务
  • 隔离界别

这几个概念大家应该都知道,但是我猜很多人没有把它们串在一起搞明白他们之间的关系,导致这三个概念各是各的,造成记忆负担,最后对整个数据库并发控制的体系也云里雾里的。


锁与事务的关系:


在计算机科学中,做并发控制都是用的“标志位”来实现的,说直白一点就是锁,我们基本上可以说计算机科学中并发控制的底层都是锁的思想。在数据库中也不例外,也是通过锁来实现并发控制的。使用上锁之后,整个数据库的读写都会对外呈现出一些特质,这些特质就是事务(ACID),原子性、一致性、隔离性、持久性。


锁与隔离级别的关系:


当然锁有很多,在数据库中有行锁、表锁、读锁、写锁等等......不同级别的锁,ACID这些特质的强弱不同,这个强弱的级别就是“隔离级别”。


所以综合起来说就是用锁来实现并发控制,对外会呈现出事务(ACID),锁的级别的不同,ACID的强弱也不同,隔离级别对应也不同。


三个东西的关系理清楚后,来回顾一下事务和隔离级别的具体内容。


事务:


事务是为了保证SQL之间不产生脏数据。innodb中默认没有被包裹在事务中的一个单条SQL就是一个事务。事务是一类特征的总称,合起来为ACID:


原子性 (Atomicity):一个事务是一个不可分割的工作单元;事务中的所有操作要么全部成功执行,要么全部不执行。如果事务中的任何部分失败,则整个事务将被回滚到事务开始前的状态。

一致性 (Consistency):在事务开始和结束时,数据库都必须处于一致状态。这意味着事务的执行不会违反任何数据库约束或规则,并且会保持业务逻辑上的一致性。一旦事务完成,它应该使数据库从一个有效状态变为另一个有效状态。

隔离性 (Isolation):并发执行的多个事务之间互不干扰,如同它们是按顺序独立执行一样。这防止了脏读(读取未提交的数据)、不可重复读(在同一事务内多次读取同一数据时结果不同)和幻读(在事务中多次执行相同的查询时,由于其他已提交事务的插入或删除操作导致结果集发生变化)等现象。

持久性 (Durability):当事务成功提交后,其对数据库所做的修改将会永久保存,即使系统发生故障(如崩溃、重启等)也不会丢失这些修改。持久性通常是通过日志记录和恢复机制来保证的。

隔离级别:


事务内具有原子性,但是事务间不具有原子性,并发情况下,多事务间仍然会存在脏数据的问题。


1、脏读:事务A读取了事务B更新的数据,然后B回滚操作,那么A读取到的数据是脏数据。


2、不可重复读:事务 A 多次读取同一数据,事务 B 在事务A多次读取的过程中,对数据作了更新并提交,导致事务A多次读取同一数据时,结果 不一致。


3、幻读:系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级,但是系统管理员B就在这个时候插入了一条具体分数的记录,当系统管理员A改结束后发现还有一条记录没有改过来,就好像发生了幻觉一样,这就叫幻读。

隔离级别就是为了保证事务之间不产生脏数据。

2.锁

2.1.分类

按照对数据的操作类型分类,分为:读锁、写锁。

按照对数据操作的粒度分类,分为:行锁、表锁、

表锁:


开销小、加锁快,无死锁,锁的粒度大,发生锁冲突的概率最高,并发度最低。


读锁:


又叫共享锁,针对同一份数据,多个读操作可以同时进行而不互相影响。针对被锁表,所有客户端都可以进行读操作,所有客户端都无法进行写操作,加锁方和其他客户端的区别是,加锁方直接不允许进行写操作,而其他客户端的写操作允许进行,只是会被阻塞挂起。锁解开后,所有挂起的操作线程会去重新争抢资源。


写锁:


又叫排它锁,当前写操作没有完成前,它会阻断其他写锁和读锁。针对被锁表,加锁方可以读写,其他客户端不行。其他客户端的写操作会直接失败,读操作会被阻塞挂起,解锁以后,被挂起的线程会重新去争抢资源。


保护机制:


读锁、写锁中,加锁方都只能读当前被自己锁定的表,这是MySQL的一个保护机制,为的就是强制要求加锁方给出一个说法,到底准备锁多久,不给说法不让走。

MySQL中不同引擎支持不同级别的锁,myIsam支持表锁,innodb支持行锁。

2.2.表锁

表锁,我们当然是要基于使用表锁的存储引擎来聊,也就是基于myIsam引擎。

myIsam引擎中的读写锁是自动加的。

myIsam引擎在解锁后的阻塞队列中进行读写锁调度是写优先,这样一旦阻塞队列中大量都是写操作,那么读操作会很难得到锁,变得很慢,从而造成永久堵塞。

当然除了自动加锁,表锁可以通过指令来加锁。

查看所有锁:

show open tables

解锁:

解铃还须系铃人,只有加锁方能解锁。

unlock  tables

加读锁:

lock table 表名 read

加写锁

lock table 表名 write

2.3.行锁(MVCC)

行锁,我们当然是要基于使用行锁的存储引擎来聊,也就是基于innodb引擎。innodb和myIsam最大的不同有两点,一是支持事务,二是采用了行级锁。innodb下读写都是自动加行锁,这没有什么好说的。但是行锁因为粒度太细了,会影响效率的,innodb没有傻傻的只用了行锁,还给出了行锁的优化方案——MVCC。


MVCC,多版本并发控制,本质上就是使用行锁锁定数据。


对于锁的实现方式来说无非就两种


悲观锁: 基于锁的并发控制,认为数据大概率会存在并发问题,所以进行数据更改前先给要操作的数据加上锁。程序员B开始修改数据时,给这些数据加上锁,程序员A这时再读,就发现读取不了,处于等待情况,只能等B操作完才能读数据,这保证A不会读到一个不一致的数据,但是这个会影响程序的运行效率。

乐观锁:基于版本号的并发控制,认为数据大概率不会存在并发问题,所以在进行数据操作的时候不加锁,而是在提交修改操作的时候通过版本号来确定数据有没有被第三方动过。

对于行级锁这种粒度这么细的锁,选用悲观锁性能肯定是不佳的,所以mvcc其实选用的都是乐观锁。


举个例子:


当使用mysql的innodb模式的时候,在mvcc的机制下,当事务A读取了表a的快照,在事务A提交前事务B又去读取了表a并且修改了数据,接下来事务A提交时会有什么效果,直接失败回滚事务还是?


在这种情况下:

事务A提交时,InnoDB会检查事务A对数据进行更新时的数据版本是否与事务A最初读取数据时的版本一致。如果事务B修改的数据行与事务A无关,那么事务A可以正常提交,因为它们操作的是不同的数据行。

如果事务B修改的数据行正好是事务A准备更新的那部分数据,由于事务A处于可重复读隔离级别,它看到的是先前的版本,不会看到事务B的修改。当事务A尝试提交时,InnoDB的事务处理机制会确保事务的一致性,通常有两种可能的结果:

a. 如果InnoDB检测到事务A试图更新的数据已经被事务B更新过(即版本冲突),事务A的更新操作可能会导致一个死锁错误(Deadlock),在这种情况下,InnoDB会选择回滚其中一个事务以解决死锁问题,通常会回滚较晚开始或者较晚修改数据的事务(在这里可能是事务A)。

b. 如果InnoDB的并发控制机制足够强大(例如使用Next-Key Locks来防止幻读),事务A在更新数据时就已经被阻止,也就是说事务A在尝试更新数据时就会被阻塞,直到事务B完成并释放锁,事务A才能继续,进而根据实际情况决定是成功提交还是因数据已改变而回滚。

2.4.如何进行事务间数据的强制同步

MySQL的MVCC是在提交的时候才比对数据是否又修改,那么有没有办法让所有事务间的数据都是强制同步的喃?有!通过关闭自动提交改为手动提交来保证修改的顺序性。


数据库默认开启自动提交,通过set autocommit=0可以关闭自动提交。


关闭后每次执行sql以后,通过commit命令来手动提交,才会对数据库产生影响,否则只会对当前操作方的数据快照有影响。innodb引擎中,其他客户端想查看到最新的数据情况也必须通过commit指令来做一次同步(因为innodb默认隔离级别为可重复读)。


当一个客户端修改某行数据,未commit前,其他客户端对该行数据的修改会阻塞挂起,直到先改那个用户commit为止。

2.5.间隙锁

使用范围条件匹配时,innodb会给符合条件的已有数据记录的索引加“范围锁”(范围锁是特殊的行锁),对于键值在条件范围内但并不存在的记录,叫做间隙(GAP),innodb也会对这个间隙加锁,这种机制叫做“间隙锁”


2.6.行锁变表锁

任何需要全表扫描的情况时,行锁都会升级为表锁。

因为MySQL不知道到底该锁哪行,所以会将整个表都锁起来,然后再进行全表扫描。


全表扫描的情况无非两种:

  1. 没建索引。
  2. 索引失效。

2.7.强制锁行

通过 for update 可以在无update操作下,强制锁定一行。

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
9天前
|
存储 SQL 关系型数据库
Mysql的四种隔离级别
Mysql的四种隔离级别
|
9天前
|
关系型数据库 MySQL 数据库
mysql事务的 四个特征(ACID)
mysql事务的 四个特征(ACID)
|
6天前
|
负载均衡 关系型数据库 MySQL
MySQL PXC集群多个节点同时大量并发update同一行
如本文标题,MySQL PXC集群多个节点同时大量并发update同一行数据,会怎样? 为此,本人做了一个测试,来验证到底会怎样!
12 0
|
18天前
|
SQL 监控 关系型数据库
MySQL-长事务详解
MySQL-长事务详解
14 0
|
24天前
|
存储 关系型数据库 MySQL
重温MySQL的ACID实现原理:深入探索底层设计与机制
重温MySQL的ACID实现原理:深入探索底层设计与机制
|
25天前
|
存储 关系型数据库 MySQL
深入解析MySQL 8:事务数据字典的变革
深入解析MySQL 8:事务数据字典的变革
|
15天前
|
存储 关系型数据库 MySQL
探索MySQL:关系型数据库的基石
MySQL,作为全球最流行的开源关系型数据库管理系统(RDBMS)之一,广泛应用于各种Web应用、企业级应用和数据仓库中
|
13天前
|
关系型数据库 MySQL 网络安全
Mysql 数据库主从复制
在MySQL主从复制环境中,配置了两台虚拟机:主VM拥有IP1,从VM有IP2。主VM的`my.cnf`设置server-id为1,启用二进制日志;从VM设置server-id为2,开启GTID模式。通过`find`命令查找配置文件,编辑`my.cnf`,在主服务器上创建复制用户,记录二进制日志信息,然后锁定表并备份数据。备份文件通过SCP传输到从服务器,恢复数据并配置复制源,启动复制。检查复制状态确认运行正常。最后解锁表,完成主从同步,新用户在从库中自动更新。
986 6
Mysql 数据库主从复制
|
13天前
|
缓存 运维 关系型数据库
数据库容灾 | MySQL MGR与阿里云PolarDB-X Paxos的深度对比
经过深入的技术剖析与性能对比,PolarDB-X DN凭借其自研的X-Paxos协议和一系列优化设计,在性能、正确性、可用性及资源开销等方面展现出对MySQL MGR的多项优势,但MGR在MySQL生态体系内也占据重要地位,但需要考虑备库宕机抖动、跨机房容灾性能波动、稳定性等各种情况,因此如果想用好MGR,必须配备专业的技术和运维团队的支持。 在面对大规模、高并发、高可用性需求时,PolarDB-X存储引擎以其独特的技术优势和优异的性能表现,相比于MGR在开箱即用的场景下,PolarDB-X基于DN的集中式(标准版)在功能和性能都做到了很好的平衡,成为了极具竞争力的数据库解决方案。
|
3天前
|
分布式计算 大数据 关系型数据库
MaxCompute产品使用合集之如何实现类似mysql实例中的数据库功能
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。