十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
mysql锁机制是在并发操作的时候,避免多人同时操作而发生错误。
成都创新互联公司是一家专业提供大名企业网站建设,专注与成都网站制作、成都网站建设、H5开发、小程序制作等业务。10年已为大名众多企业、政府机构等服务。创新互联专业网站设计公司优惠进行中。
先说一下表级锁吧
表级锁 一般引擎都支持,资源消耗小。申请锁的时候 整表锁定(分读写锁),其它线程或操作不能进行操作
行级锁 INNODB引擎支持。资源消耗大 锁定的时候 被锁的行只能进行一个操作 其它均不能操作些行。
InnoDB默认是行级别的锁,当有明确指定的主键时候,是行级锁。否则是表级别。
例子: 假设表foods ,存在有id跟name、status三个字段,id是主键,status有索引。
例1: (明确指定主键,并且有此记录,行级锁)
例2: (明确指定主键/索引,若查无此记录,无锁)
例3: (无主键/索引,表级锁)
例4: (主键/索引不明确,表级锁)
for update的注意点
for update的疑问点
锁是计算机协调多个进程或线程并发访问某一资源的机制,在数据库中,除传统的计算资源(CPU、RAM、I/O)争用外,数据也是一种供许多用户共享的资源,如何保证数据并发访问的一致性,有效性是所有数据库必须解决的一个问题,锁冲突也是影响数据库并发访问性能的一个重要因素,从这个角度来说,锁对数据库而言是尤其重要,也更加复杂。MySQL中的锁,按照锁的粒度分为:1、全局锁,就锁定数据库中的所有表。2、表级锁,每次操作锁住整张表。3、行级锁,每次操作锁住对应的行数据。
全局锁就是对整个数据库实例加锁,加锁后整个实例就处于只读状态,后续的DML的写语句,DDL语句,已经更新操作的事务提交语句都将阻塞。其典型的使用场景就是做全库的逻辑备份,对所有的表进行锁定,从而获取一致性视图,保证数据的完整性。但是对数据库加全局锁是有弊端的,如在主库上备份,那么在备份期间都不能执行更新,业务会受影响,第二如果是在从库上备份,那么在备份期间从库不能执行主库同步过来的二进制日志,会导致主从延迟。
解决办法是在innodb引擎中,备份时加上--single-transaction参数来完成不加锁的一致性数据备份。
添加全局锁: flush tables with read lock; 解锁 unlock tables。
表级锁,每次操作会锁住整张表.锁定粒度大,发送锁冲突的概率最高,并发读最低,应用在myisam、innodb、BOB等存储引擎中。表级锁分为: 表锁、元数据锁(meta data lock, MDL)和意向锁。
表锁又分为: 表共享读锁 read lock、表独占写锁write lock
语法: 1、加锁 lock tables 表名 ... read/write
2、释放锁 unlock tables 或者关闭客户端连接
注意: 读锁不会阻塞其它客户端的读,但是会阻塞其它客户端的写,写锁既会阻塞其它客户端的读,又会阻塞其它客户端的写。大家可以拿一张表来测试看看。
元数据锁,在加锁过程中是系统自动控制的,无需显示使用,在访问一张表的时候会自动加上,MDL锁主要作用是维护表元数据的数据一致性,在表上有活动事务的时候,不可以对元数据进行写入操作。为了避免DML和DDL冲突,保证读写的正确性。
在MySQL5.5中引入了MDL,当对一张表进行增删改查的时候,加MDL读锁(共享);当对表结构进行变更操作时,加MDL写锁(排他).
查看元数据锁:
select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema_metadata_locks;
意向锁,为了避免DML在执行时,加的行锁与表锁的冲突,在innodb中引入了意向锁,使得表锁不用检查每行数据是否加锁,使用意向锁来减少表锁的检查。意向锁分为,意向共享锁is由语句select ... lock in share mode添加。意向排他锁ix,由insert,update,delete,select。。。for update 添加。
select object_schema,object_name,index_name,lock_type,lock_mode,lock_data from performance_schema.data_lock;
行级锁,每次操作锁住对应的行数据,锁定粒度最小,发生锁冲突的概率最高,并发读最高,应用在innodb存储引擎中。
innodb的数据是基于索引组织的,行锁是通过对索引上的索引项加锁来实现的,而不是对记录加的锁,对于行级锁,主要分为以下三类:
1、行锁或者叫record lock记录锁,锁定单个行记录的锁,防止其他事物对次行进行update和delete操作,在RC,RR隔离级别下都支持。
2、间隙锁Gap lock,锁定索引记录间隙(不含该记录),确保索引记录间隙不变,防止其他事物在这个间隙进行insert操作,产生幻读,在RR隔离级别下都支持。
3、临键锁Next-key-lock,行锁和间隙锁组合,同时锁住数据,并锁住数据前面的间隙Gap,在RR隔离级别下支持。
innodb实现了以下两种类型的行锁
1、共享锁 S: 允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁。
2、排他锁 X: 允许获取排他锁的事务更新数据,阻止其他事务获得相同数据集的共享锁和排他锁。
insert 语句 排他锁 自动添加的
update语句 排他锁 自动添加
delete 语句 排他锁 自动添加
select 正常查询语句 不加锁 。。。
select 。。。lock in share mode 共享锁 需要手动在select 之后加lock in share mode
select 。。。for update 排他锁 需要手动在select之后添加for update
默认情况下,innodb在repeatable read事务隔离级别运行,innodb使用next-key锁进行搜索和索引扫描,以防止幻读。
间隙锁唯一目的是防止其它事务插入间隙,间隙锁可以共存,一个事务采用的间隙锁不会阻止另一个事务在同一间隙上采用的间隙锁。
当多个用户访问同一份数据时,一个用户在更改数据的过程中,可能有其他用户同时发起更改请求,为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态,使用事务处理是非常必要的,事务具有以下四个特性:
MySQL 提供了多种事务型存储引擎,如 InnoDB 和 BDB 等,而 MyISAM 不支持事务。为了支持事务,InnoDB 存储引擎引入了与事务处理相关的 REDO 日志和 UNDO 日志,同时事务依赖于 MySQL 提供的锁机制
事务执行时需要将执行的事务日志写入日志文件,对应的文件为 REDO 日志。当每条 SQL 进行数据更新操作时,首先将 REDO 日志写进日志缓冲区。当客户端执行 COMMIT 命令提交时,日志缓冲区的内容将被刷新到磁盘,日志缓冲区的刷新方式或者时间间隔可以通过参数 innodb_flush_log_at_trx_commit 控制
REDO 日志对应磁盘上的 ib_logifleN 文件,该文件默认为 5MB,建议设置为 512MB,以便容纳较大的事务。MySQL 崩溃恢复时会重新执行 REDO 日志的记录,恢复最新数据,保证已提交事务的持久性
与 REDO 日志相反,UNDO 日志主要用于事务异常时的数据回滚,具体内容就是记录数据被修改前的信息到 UNDO 缓冲区,然后在合适的时间将内容刷新到磁盘
假如由于系统错误或者 rollback 操作而导致事务回滚,可以根据 undo 日志回滚到没修改前的状态,保证未提交事务的原子性
与 REDO 日志不同的是,磁盘上不存在单独的 UNDO 日志文件,所有的 UNDO 日志均存在表空间对应的 .ibd 数据文件中,即使 MySQL 服务启动了独立表空间
在 MySQL 中,可以使用 BEGIN 开始事务,使用 COMMIT 结束事务,中间可以使用 ROLLBACK 回滚事务。MySQL 通过 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等语句支持本地事务
MySQL 定义了四种隔离级别,指定事务中哪些数据改变其他事务可见、哪些数据该表其他事务不可见。低级别的隔离级别可以支持更高的并发处理,同时占用的系统资源更少
InnoDB 系统级事务隔离级别可以使用以下语句设置:
查看系统级事务隔离级别:
InnoDB 会话级事务隔离级别可以使用以下语句设置:
查看会话级事务隔离级别:
在该隔离级别,所有事务都可以看到其他未提交事务的执行结果。读取未提交的数据称为脏读(Dirty Read),即是:首先开启 A 和 B 两个事务,在 B 事务更新但未提交之前,A 事务读取到了更新后的数据,但由于 B 事务回滚,导致 A 事务出现了脏读现象
所有事务只能看见已经提交事务所做的改变,此级别可以解决脏读,但也会导致不可重复读(Nonrepeatable Read):首先开启 A 和 B 两个事务,A事务读取了 B 事务的数据,在 B 事务更新并提交后,A 事务又读取到了更新后的数据,此时就出现了同一 A 事务中的查询出现了不同的查询结果
MySQL 默认的事务隔离级别,能确保同一事务的多个实例在并发读取数据时看到同样的数据行,理论上会导致一个问题,幻读(Phontom Read)。例如,第一个事务对一个表中的数据做了修改,这种修改会涉及表中的全部数据行,同时第二个事务也修改这个表中的数据,这次的修改是向表中插入一行新数据,此时就会发生操作第一个事务的用户发现表中还有没有修改的数据行
InnoDB 通过多版本并发控制机制(MVCC)解决了该问题:InnoDB 通过为每个数据行增加两个隐含值的方式来实现,这两个隐含值记录了行的创建时间、过期时间以及每一行存储时间发生时的系统版本号,每个查询根据事务的版本号来查询结果
通过强制事务排序,使其不可能相互冲突,从而解决幻读问题。简而言之,就是在每个读的数据行上加上共享锁实现,这个级别会导致大量的超时现象和锁竞争,一般不推荐使用
为了解决数据库并发控制问题,如走到同一时刻客户端对同一张表做更新或者查询操作,需要对并发操作进行控制,因此产生了锁
共享锁的粒度是行或者元组(多个行),一个事务获取了共享锁以后,可以对锁定范围内的数据执行读操作
排他锁的粒度与共享锁相同,一个事务获取排他锁以后,可以对锁定范围内的数据执行写操作
有两个事务 A 和 B,如果事务 A 获取了一个元组的共享锁,事务 B 还可以立即获取这个元组的共享锁,但不能获取这个元组的排他锁,必须等到事务 A 释放共享锁之后。如果事务 A 获取了一个元组的排他锁,事务 B 不能立即获取这个元组的共享锁,也不能立即获取这个元组的排他锁,必须等到 A 释放排他锁之后
意向锁是一种表锁,锁定的粒度是整张表,分为意向共享锁和意向排他锁。意向共享锁表示一个事务有意对数据上共享锁或者排他锁。有意表示事务想执行操作但还没真正执行
锁的粒度主要分为表锁和行锁
表锁的开销最小,同时允许的并发量也是最小。MyISAM 存储引擎使用该锁机制。当要写入数据时,整个表记录被锁,此时其他读/写动作一律等待。一些特定的动作,如 ALTER TABLE 执行时使用的也是表锁
行锁可以支持最大的并发,InnoDB 存储引擎使用该锁机制。如果要支持并发读/写,建议采用 InnoDB 存储引擎
MySQL 中原数据锁是系统自动控制添加的,对于用户来说无需显示调用,当我们使用一张表的时候就会加上原数据锁。
原数据锁的作用是为了保护表原数据的一致性,如果在表上有活动事务的时候,不可以对元数据进行写入操作。也就是为了避免DML 和DDL 之间的冲突,保证读写的正确性。
说白了就是, 在对数据表进行读写操作的时候,不能进行修改表结构的操作 。
如上图所示,在执行select 操作的时候,MySQL 会自动加上shared_read 锁,在insert,update, delete 以及 select for update 操作的时候会加上shared_write 锁,这两类锁是兼容的。
在执行alter table 操作的时候,会加上 exclusive 锁,这个锁与shared_read 和 shared_write 锁 是互斥的,换句话说在 做查询和更新表数据的时候,是不能够修改表结构 的。
来看个例子
首先开启事务,使用select 语句会针对表加上shared_read的共享锁
begin;
select * from course;
此时查看原数据锁的信息
select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks;
通过上图我们可以发现,course 表加上了shared_read锁。
接着,开启另外一个事务,记住刚才的事务不要commit
begin;
update course set name = 'Jason' where id =2;
如上图所示,此时的update 语句可以执行成功,并没有被阻塞。说明select 和update 是不冲突的,他们的锁是兼容的。
再次查看原数据锁
select object_type,object_schema,object_name,lock_type,lock_duration from performance_schema.metadata_locks;
从上面的截图可以看出,此时原数据锁的表中记录了两条记录分别是针对course 表的shared_read 和 shared_write 锁,也刚好对应我们执行的select 和update 操作。
最后,我们再启动第三个客户端,并且启动 第三个事务,执行alter语句,在course 表中加入一个字段hello 如下 。
begin;
alter table course add column hello int;
由于之前的事务没有提交所以修改表的操作会被阻塞, 因为shared_read 以及 shared_write 这两个锁 与 exclusive之间是互斥的,所以会阻塞 。
此时,回到最开始的两个客户端,对两个事务进行commit 操作,再返回到第三个事务执行的alter 语句出,发现语句顺利执行。