当前位置:威尼斯 > 数据库 > 更新时再申请排他锁威尼斯,  检索条件有索

更新时再申请排他锁威尼斯,  检索条件有索

文章作者:数据库 上传时间:2019-09-19

一. 概述

  通常来说,死锁都是应用设计问题,通过调整业务流程,数据库对象设计,事务大小,以及访问数据库的sql语句,绝大部分死锁都可以避免,下面介绍几种避免死锁的常用 方法.
  1. 在应用中,如果不同的程序并发操作多个表,应尽量约定以相同的顺序来访问表,这样可以大大降低产生死锁的机会。按顺序对表进行操作,是很常用的一种避免死锁的操作。 比如:有二个不一样的存储过程,同时在对一个表进行复杂的删改操作。这种情况可以考虑先让一个执行完成,再让另一个在执行。
  2. 在程序中以批量方式处理数据的时候,如果事先对数据排序,保证每个线程按固定的顺序来处理记录,也可以大大降低出现死锁的可能。比如常见的就是多线程下在程序中lock锁住,在进程下保持串行处理。
  3. 在事务中,如果要更新记录,应该直接申请足够级别的锁,即排它锁,而不是先申请共享锁,更新时再申请排他锁,因为当用户申请排他锁时,其它事务可能又已经获得了相同记录的共享锁,从而造成锁冲突。 我理解是在事务中首先将要更新的记录,以select .. for update方式获得排它锁, 在事务里处理完逻辑后就可以直接更新而不用考虑锁冲突。 代码如下:

SET autocommit=0
-- 将要更新的数据先获得排它锁
SELECT * FROM city WHERE city_id=103 FOR UPDATE;
-- 逻辑处理  ....
-- 最后更新可以避免锁冲突
UPDATE city SET cityname='杭州' WHERE city_id=103;
COMMIT;

  4. 在默认级别Repeatable read下, 如果两个线程同时对相同条件记录用 select .. for update 加排它锁,在没有符合该条件记录情况下,两个线程都会加锁成功。当一个程序发现记录不存在,就试图插入一条新数据,如果两个线程都这么做,就会出现死锁。这是因为在Repeatable read下产生了间隙锁。这种情况下,将隔离级别改成Read commited,就可避免问题 如下图表格 贴出了二个隔离级别下产生锁的差异。

威尼斯 1

  5. 当在Repeatable read下,如果两个线程都先执行select .. for update。 在判断是否存在符合条件的记录,如果没有,就插入记录,此时,只有一个线程能插入成功,另一个线程会出现锁等待, 当第1个线程提交后,第2个线程如因为主键值重复,会出现异常。但却获得了一个排它锁, 需要执行rollback释放排它锁。避免影响其它事务。
  总结:尽管通过上面介绍和sql 优化等措施,可以大大减少死锁,但死锁很难完全避免。因此。 在程序设计中总是捕获并处理死锁异常是一个很好的编程习惯。在程序异常里或commit或rollback。

事务

在InnoDB加锁前,为什么要先start transaction

  innodb下锁的释放在事务提交/回滚之后,事务一旦提交/回滚之后,就会自动释放事务中的锁,innodb默认情况下autocommit=1即开启自动提交

检索条件使用索引和不使用索引的锁区别:

  检索条件有索引的情况下会锁定特定的一些行。

检索条件没有使用使用的情况下会进行全表扫描,从而锁定全部的行(包括不存在的记录)

二. 检查死锁产生的原因

  如果出现死锁,可以用SHOW ENGINE INNODB STATUS 命令来确定最后一个死锁产生的原因。返回结果中包括死锁相关事务的详细信息,如引发死锁的sql语句,事务已经获得的锁,正在等待什么锁,以及被回滚的事务等,以此分析死锁产生的原因和改进措施。

-- 查看最后一个死锁
SHOW ENGINE  INNODB STATUS;

LATEST DETECTED DEADLOCK
------------------------
2018-08-02 18:07:45 0x7f3a12209700
*** (1) TRANSACTION:
TRANSACTION 35489574, ACTIVE 114 sec STARTING INDEX READ
mysql TABLES IN USE 1, locked 1
LOCK WAIT 4 LOCK struct(s), HEAP size 1136, 2 ROW LOCK(s)
MySQL thread id 2634494, OS thread handle 139887387092736, QUERY id 109768880 172.168.18.202 root Sending DATA
-- 因为会话2 已获得排他锁, 些语句 等待
 SELECT * FROM cityNew  WHERE city_id=103 FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS SPACE id 479 page NO 3 n bits 72 INDEX GEN_CLUST_INDEX of TABLE `test`.`cityNew` trx id 35489574 lock_mode X waiting
*** (2) TRANSACTION:
TRANSACTION 35489577, ACTIVE 8 sec STARTING INDEX READ, thread declared inside INNODB 5000
mysql TABLES IN USE 1, locked 1
4 LOCK struct(s), HEAP size 1136, 3 ROW LOCK(s)
MySQL thread id 2634624, OS thread handle 139887388956416, QUERY id 109768953 172.168.18.202 root statistics
-- 死锁
 SELECT * FROM city  WHERE city_id=103 FOR UPDATE
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS SPACE id 479 page NO 3 n bits 72 INDEX GEN_CLUST_INDEX of TABLE `test`.`cityNew` trx id 35489577 lock_mode X
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS SPACE id 477 page NO 3 n bits 80 INDEX PRIMARY of TABLE `test`.`city` trx id 35489577 lock_mode X LOCKS rec but NOT gap waiting
*** WE ROLL BACK TRANSACTION (2)
------------

1.事务的概念:

事务是指逻辑上的一组操作,这组操作要么同时完成要么同时不完成。参考转账操作。

读锁:

  读锁是共享的,或者说是相互不阻塞的。多个用户在同一时刻可以同时读取同一个资源,而互不干扰。

2.

如果你自己不去控制事务,数据库默认一条sql语句就处在自己单独的事务当中。

写锁:

  写锁是排他的,也就是说一个写锁会阻塞其他的写锁和读锁。另外写锁比读锁有更高的优先级,因此一个写锁请求可能会被插入到读锁 队列的前面,但是读锁则不可能插入到写锁的前面

3.也可以使用命令去开启一个事务:

start transaction;--开启事务,这条语句之后的sql语句将处在一个事务当中,这些sql语句并不会立即执行

Commit--提交事务,一旦提交事务,事务中的所有sql语句才会执行。

Rollback -- 回滚事务,将之前所有的sql取消。

conn.setAutoCommit(false);

conn.commit();

conn.rollback();

conn.setSavePoint();

conn.rollback(sp);

表锁:

  InnoDB还有两个表锁:意向共享锁(IS),意向排它锁(IX)

4.事务的四大特性ACID

(1)原子性:事务的一组操作是原子的不可再分割的,这组操作要么同时完成要么同时不完成。

(2)一致性: 事务在执行前后数据的完整性保持不变。数据库在某个状态下符合所有的完整性约束的状态叫做数据库具有完整性。在解散一个部门时应该同时处理员工表中的员工保证这个事务结束后,仍然保证所有的员工能找到对应的部门,满足外键约束。

(3)隔离性:当多个事务同时操作一个数据库时,可能存在并发问题,此时应保证各个事务要进行隔离,事务之间不能互相干扰。

(4)持久性:持久性是指一个事务一旦被提交,它对数据库中数据的改变就是永久性的,不能再回滚。

行锁:

  InnoDB实现了两种类型行级锁,共享锁和排它锁

威尼斯 2

5.事务的隔离性导致的问题(所有的问题都是在某些情况下才会导致问题)

~脏读:一个事务读取到了另一个事务未提交的数据。

1 | a    |  1000

2 | b    |  1000

b--->a

start transaction;

update account set money=money-100 where name='b';

update account set money=money+100 where name='a';

rollback;

select * from account where name = 'a';1000 1000

~不可重复读:在一个事务内读取表中的某一行数据,多次读取结果不同.

start transaction:

活期存款:1000

定期存款:1000

固定资产: 2000


开启事务

取走获取存款1000

提交事务


总资产:3000

~幻读(虚读):一个事务读取到了另一个事务插入的数据(已提交)

a 2000

b 2000

c 2000

start transaction;

select sum(money) from account;6000


开启事务

创建一个账户并存入1000块钱

提交了事务


select count(*)from account;4

avgMoney = allMoney/count;6000/4=1500

乐观锁:

  乐观锁,也叫乐观并发控制,它假设多用户并发的事务在处理时不会彼此互相影响,各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前,每个事务会先检查在该事务读取数据后,有没有其他事务又修改了该数据。如果其他事务有更新的话,那么当前正在提交的事务会进行回滚。

6.数据库的隔离级别

~Read uncommitted:如果将数据库设定为此隔离级别,数据库将会有脏读、不可重复度、幻读的问题。

~Read committed:如果将数据库设定为此隔离级别,数据库可以防止脏读,但有不可重复度、幻读的问题。

~Repeatable read: 如果将数据库设定为此隔离级别,数据库可以防止脏读、不可重复度,但是不能防止幻读。

~Serializable:将数据库串行化,可以避免脏读、不可重复读、幻读。

安全性来说:Serializable>Repeatable read>Read committed>Read uncommitted

效率来说:Serializable<Repeatable read<Read committed

通常来说,一般的应用都会选择Repeatable read或Read committed作为数据库隔离级别来使用。

mysql默认的数据库隔离级别为:REPEATABLE-READ

如何查询当前数据库的隔离级别?select @@tx_isolation;

如何设置当前数据库的隔离级别?set [global/session] transaction isolation level ...;

~此种方式设置的隔离级别只对当前连接起作用。

set transaction isolation level read uncommitted;

set session transaction isolation level read uncommitted;

~此种方式设置的隔离级别是设置数据库默认的隔离级别

set global transaction isolation level read uncommitted;

悲观锁:

  悲观锁,也叫悲观并发控制,当事务A对某行数据应用了锁,并且当这个事务把锁释放后,其他事务才能够执行与该锁冲突的操作,这里事务A所施加的锁就叫悲观锁。共享锁和排他锁(行锁,间隙锁,next-key lock)都属于悲观锁

7.锁机制:

共享锁:共享锁和共享锁可以共存。

排他锁:排他锁和所有锁都不能共存。

在非串行化下,所有的查询都不加锁,所有的修改操作都会加排他锁。

在串行化下,所有的查询都加共享锁,所有的修改都加排他锁。

死锁

悲观锁与乐观锁的实现方式:

  悲观锁的实现依靠的是数据库提供的锁机制来实现,例如select * from news where id=12 for update,而乐观锁依靠的是记录数据版本来实现,即通过在表中添加版本号字段来作为是否可以成功提交的关键因素。

威尼斯 3

8.更新丢失

如果多个线程操作,基于同一个查询结构对表中的记录进行修改,那么后修改的记录将会覆盖前面修改的记录,前面的修改就丢失掉了,这就叫做更新丢失。

Serializable可以防止更新丢失问题的发生。其他的三个隔离级别都有可能发生更新丢失问题。

Serializable虽然可以防止更新丢失,但是效率太低,通常数据库不会用这个隔离级别,所以我们需要其他的机制来防止更新丢失:

乐观锁和悲观锁不是数据库中真正存在的锁,只是人们在解决更新丢失时的不同的解决方案,体现的是人们看待事务的态度。

悲观锁:

隔离级别不设置为Serializable,防止效率过低。

在查询时手动加上排他锁。

如果数据库中的数据查询比较多而更新比较少的话,悲观锁将会导致效率低下。

乐观锁:

在表中增加一个version字段,在更新数据库记录是将version加一,从而在修改数据时通过检查版本号是否改变判断出当前更新基于的查询是否已经是过时的版本。

如果数据库中数据的修改比较多,更新失败的次数会比较多,程序需要多次重复执行更新操作。

共享锁(S):

  共享锁也叫读锁,一个事务获取了一个数据行的共享锁,其他事务能获得该行对应的共享锁,但不能获得排他锁,即一个事务在读取一个数据行的时候,其他事务也可以读,但不能对该数据行进行增删改

  设置共享锁: SELECT .... LOCK IN SHARE MODE;

排它锁(X):

  排它锁也叫写锁,一个事务获取了一个数据行的排他锁,其他事务就不能再获取该行的其他锁(排他锁或者共享锁),即一个事务在读取一个数据行的时候,其他事务不能对该数据行进行增删改查

  设置排它锁:SELECT .... FOR UPDATE

  注意点:

  • 对于select 语句,innodb不会加任何锁,也就是可以多个并发去进行select的操作,不会有任何的锁冲突,因为根本没有锁。
  • 对于insert,update,delete操作,innodb会自动给涉及到的数据加排他锁,只有查询select需要我们手动设置排他锁。

意向共享锁(IS):

  通知数据库接下来需要施加什么锁并对表加锁。如果需要对记录A加共享锁,那么此时innodb会先找到这张表,对该表加意向共享锁之后,再对记录A添加共享锁。也就是说一个数据行加共享锁前必须先取得该表的IS锁

意向排它锁(IX):

  通知数据库接下来需要施加什么锁并对表加锁。如果需要对记录A加排他锁,那么此时innodb会先找到这张表,对该表加意向排他锁之后,再对记录A添加共享锁。也就是说一个数据行加排它锁前必须先取得该表的IX锁

  共享锁和意向共享锁,排他锁与意向排他锁的区别:

  • 共享锁和排他锁,系统在特定的条件下会自动添加共享锁或者排他锁,也可以手动添加共享锁或者排他锁。
  • 意向共享锁和意向排他锁都是系统自动添加和自动释放的,整个过程无需人工干预。
  • 共享锁和排他锁都是锁的行记录,意向共享锁和意向排他锁锁定的是表。

 锁的实现方式:

  在MySQL中,行级锁并不是直接锁记录,而是锁索引。索引分为主键索引和非主键索引两种,如果一条sql语句操作了主键索引,MySQL就会锁定这条主键索引;如果一条语句操作了非主键索引,MySQL会先锁定该非主键索引,再锁定相关的主键索引。

  InnoDB行锁是通过给索引项加锁实现的,如果没有索引,InnoDB会通过隐藏的聚簇索引来对记录加锁。也就是说:如果不通过索引条件检索数据,那么InnoDB将对表中所有数据加锁,实际效果跟表锁一样

行锁分为三种情况:

  Record Lock:对索引项加锁,即锁定一条记录。

  Gap Lock:对索引项之间的 ‘间隙’ 、对第一条记录前的间隙或最后一条记录后的间隙加锁,即锁定一个范围的记录,不包含记录本身

  Next-key Lock:锁定一个范围的记录并包含记录本身(上面两者的结合)

  注意:InnoDB默认级别是repeatable-read(重复读)级别。ANSI/IOS SQL标准定义了4种事务隔离级别:未提交读(read uncommitted),提交读(read committed),重复读(repeatable read),串行读(serializable)

Gap Lock和Next-key Lock的区别:

  Next-Key Lock是行锁与间隙锁的组合,这样,当InnoDB扫描索引记录的时候,会首先对选中的索引记录加上行锁(Record Lock),再对索引记录两边的间隙加上间隙锁(Gap Lock)。如果一个间隙被事务T1加了锁,其它事务是不能在这个间隙插入记录的。

  行锁防止别的事务修改或删除,Gap锁防止别的事务新增,行锁和GAP锁结合形成的Next-Key锁共同解决了RR界别在写数据时的幻读问题。

何时在InnoDB中使用表锁:

  InnoDB在绝大部分情况会使用行级锁,因为事务和行锁往往是我们选择InnoDB的原因,但是有些情况下我们也考虑使用表级锁

  • 当事务需要更新大部分数据时,表又比较大,如果使用默认的行锁,不仅效率低,而且还容易造成其他事务长时间等待和锁冲突。
  • 事务比较复杂,很可能引起死锁导致回滚。

在InnoDB下 ,使用表锁要注意以下两点。

    (1)使用LOCK TALBES虽然可以给InnoDB加表级锁,但必须说明的是,表锁不是由InnoDB存储引擎层管理的,而是由其上一层MySQL Server负责的,仅当autocommit=0、innodb_table_lock=1(默认设置)时,InnoDB层才能知道MySQL加的表锁,MySQL Server才能感知InnoDB加的行锁,这种情况下,InnoDB才能自动识别涉及表级锁的死锁;否则,InnoDB将无法自动检测并处理这种死锁。

    (2)在用LOCAK TABLES对InnoDB锁时要注意,要将AUTOCOMMIT设为0,否则MySQL不会给表加锁;事务结束前,不要用UNLOCAK TABLES释放表锁,因为UNLOCK TABLES会隐含地提交事务;COMMIT或ROLLBACK不能释放用LOCAK TABLES加的表级锁,必须用UNLOCK TABLES释放表锁,正确的方式见如下:

  例如:如果需要写表t1并从表t读

  

SET AUTOCOMMIT=0;
LOCAK TABLES t1 WRITE, t2 READ, ...;
[do something with tables t1 and here];
COMMIT;
UNLOCK TABLES;

 死锁:

  我们说过MyISAM中是不会产生死锁的,因为MyISAM总是一次性获得所需的全部锁,要么全部满足,要么全部等待。而在InnoDB中,锁是逐步获得的,就造成了死锁的可能。

     发生死锁后,InnoDB一般都可以检测到,并使一个事务释放锁回退,另一个获取锁完成事务。但在涉及外部锁,或涉及锁的情况下,InnoDB并不能完全自动检测到死锁,这需要通过设置锁等待超时参数innodb_lock_wait_timeout来解决。需要说明的是,这个参数并不是只用来解决死锁问题,在并发访问比较高的情况下,如果大量事务因无法立即获取所需的锁而挂起,会占用大量计算机资源,造成严重性能问题,甚至拖垮数据库。我们通过设置合适的锁等待超时阈值,可以避免这种情况发生。

  有多种方法可以避免死锁,这里介绍常见的三种:

  1. 如果不同程序会并发存取多个表,尽量约定以相同的顺序访问表,可以大大降低死锁机会。如果两个session访问两个表的顺序不同,发生死锁的机会就非常高!但如果以相同的顺序来访问,死锁就可能避免。
  2. 在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁产生概率。
  3. 对于非常容易产生死锁的业务部分,可以尝试使用升级锁定颗粒度,通过表级锁定来减少死锁产生的概。
  4. 在程序以批量方式处理数据的时候,如果事先对数据排序,保证每个线程按固定的顺序来处理记录,也可以大大降低死锁的可能
  5. 在REPEATEABLE-READ隔离级别下,如果两个线程同时对相同条件记录用SELECT...ROR UPDATE加排他锁,在没有符合该记录情况下,两个线程都会加锁成功。程序发现记录尚不存在,就试图插入一条新记录,如果两个线程都这么做,就会出现死锁。这种情况下,将隔离级别改成READ COMMITTED,就可以避免问题。
  6. 当隔离级别为READ COMMITED时,如果两个线程都先执行SELECT...FOR UPDATE,判断是否存在符合条件的记录,如果没有,就插入记录。此时,只有一个线程能插入成功,另一个线程会出现锁等待,当第1个线程提交后,第2个线程会因主键重出错,但虽然这个线程出错了,却会获得一个排他锁!这时如果有第3个线程又来申请排他锁,也会出现死锁。对于这种情况,可以直接做插入操作,然后再捕获主键重异常,或者在遇到主键重错误时,总是执行ROLLBACK释放获得的排他锁

   ps:如果出现死锁,可以用SHOW INNODB STATUS命令来确定最后一个死锁产生的原因和改进措施。

 总结:

  对于InnoDB表,主要有以下几点

    (1)InnoDB的行销是基于索引实现的,如果不通过索引访问数据,InnoDB会使用表锁。

    (2)InnoDB间隙锁机制,以及InnoDB使用间隙锁的原因。

    (3)在不同的隔离级别下,InnoDB的锁机制和一致性读策略不同。

    (4)MySQL的恢复和复制对InnoDB锁机制和一致性读策略也有较大影响。

    (5)锁冲突甚至死锁很难完全避免。

 

      在了解InnoDB的锁特性后,用户可以通过设计和SQL调整等措施减少锁冲突和死锁,包括:

  • 尽量使用较低的隔离级别
  • 精心设计索引,并尽量使用索引访问数据,使加锁更精确,从而减少锁冲突的机会。
  • 选择合理的事务大小,小事务发生锁冲突的几率也更小。
  • 给记录集显示加锁时,最好一次性请求足够级别的锁。比如要修改数据的话,最好直接申请排他锁,而不是先申请共享锁,修改时再请求排他锁,这样容易产生死锁。
  • 不同的程序访问一组表时,应尽量约定以相同的顺序访问各表,对一个表而言,尽可能以固定的顺序存取表中的行。这样可以大减少死锁的机会。
  • 尽量用相等条件访问数据,这样可以避免间隙锁对并发插入的影响。
  • 不要申请超过实际需要的锁级别;除非必须,查询时不要显示加锁。
  • 对于一些特定的事务,可以使用表锁来提高处理速度或减少死锁的可能。

参考文献:

 [1] Baron Schwartz等 著,宁海元等 译 ;《高性能MySQL》(第3版); 电子工业出版社 ,2013

 [2] 简书博客,

 [3]CSDN博客,

 [4] CSDN博客,

 [5] CSDN博客,

 [6] CSDN博客,

 [7] CSDN博客,

 [8] 官网文档,

本文由威尼斯发布于数据库,转载请注明出处:更新时再申请排他锁威尼斯,  检索条件有索

关键词: