MYSQL InnoDB表锁

InnoDB锁问题
InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。行级锁与表级锁本来就有许多不同之处，另外，事务的引入也带来了一些新问题。下面我们先介绍一点背景知识，然后详细讨论InnoDB的锁问题。

2．并发事务处理带来的问题
相对于串行处理来说，并发事务处理能大大增加数据库资源的利用率，提高数据库系统的事务吞吐量，从而可以支持更多的用户。但并发事务处理也会带来一些问题，主要包括以下几种情况。
     更新丢失（ost Update）：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题－－最后的更新覆盖了由其他事务所做的更新。例如，两个编辑人员制作了同一文档的电子副本。每个编辑人员独立地更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改副本的编辑人员覆盖另一个编辑人员所做的更改。如果在一个编辑人员完成并提交事务之前，另一个编辑人员不能访问同一文件，则可避免此问题。
     脏读（Dirty Reads）：一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象地叫做"脏读"。
     不可重复读（Non-Repeatabe Reads）：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了！这种现象就叫做“不可重复读”。
     幻读（Phantom Reads）：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。
3．事务隔离级别
在上面讲到的并发事务处理带来的问题中，“更新丢失”通常是应该完全避免的。但防止更新丢失，并不能单靠数据库事务控制器来解决，需要应用程序对要更新的数据加必要的锁来解决，因此，防止更新丢失应该是应用的责任。
“脏读”、“不可重复读”和“幻读”，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。数据库实现事务隔离的方式，基本上可分为以下两种。
  一种是在读取数据前，对其加锁，阻止其他事务对数据进行修改。
  另一种是不用加任何锁，通过一定机制生成一个数据请求时间点的一致性数据快照（Snapshot)，并用这个快照来提供一定级别（语句级或事务级）的一致性读取。从用户的角度来看，好象是数据库可以提供同一数据的多个版本，因此，这种技术叫做数据多版本并发控制（MutiVersion Concurrency Contro，简称MVCC或MCC），也经常称为多版本数据库。
数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上 “串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏感，可能更关心数据并发访问的能力。
为了解决“隔离”与“并发”的矛盾，ISO/ANSI SQ92定义了4个事务隔离级别，每个级别的隔离程度不同，允许出现的副作用也不同，应用可以根据自己的业务逻辑要求，通过选择不同的隔离级别来平衡 “隔离”与“并发”的矛盾。表20-5很好地概括了这4个隔离级别的特性。

 最后要说明的是：各具体数据库并不一定完全实现了上述4个隔离级别，例如，Oracle只提供Read committed和Serializable两个标准隔离级别，另外还提供自己定义的Read only隔离级别；SQL Server除支持上述ISO/ANSI SQL92定义的4个隔离级别外，还支持一个叫做“快照”的隔离级别，但严格来说它是一个用MVCC实现的Serializable隔离级别。MySQL 支持全部4个隔离级别，但在具体实现时，有一些特点，比如在一些隔离级别下是采用MVCC一致性读，但某些情况下又不是，这些内容在后面的章节中将会做进 一步介绍。

 

获取InnoDB行锁争用情况    

可以通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况：

Java代码  

  1. mysql> show status like 'innodb_row_lock%';  
  2. +-------------------------------+-------+  
  3. | Variable_name                 | Value |  
  4. +-------------------------------+-------+  
  5. | InnoDB_row_lock_current_waits | 0     |  
  6. | InnoDB_row_lock_time          | 0     |  
  7. | InnoDB_row_lock_time_avg      | 0     |  
  8. | InnoDB_row_lock_time_max      | 0     |  
  9. | InnoDB_row_lock_waits         | 0     |  
  10. +-------------------------------+-------+  
  11. 5 rows in set (0.01 sec)  

如果发现锁争用比较严重，如InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比较高，还可以通过设置InnoDB Monitors来进一步观察发生锁冲突的表、数据行等，并分析锁争用的原因。具体方法如下：

Java代码  

  1. mysql> CREATE TABLE innodb_monitor(a INT) ENGINE=INNODB;  
  2. Query OK, 0 rows affected (0.14 sec)   

 然后就可以用下面的语句来进行查看：

Java代码  

  1. mysql> Show innodb status\G;  
  2. *************************** 1. row ***************************  
  3.   Type: InnoDB  
  4.   Name:  
  5. Status:  

 监视器可以通过发出下列语句来停止查看：

Java代码  

  1. mysql> DROP TABLE innodb_monitor;  
  2. Query OK, 0 rows affected (0.05 sec)  

 设置监视器后，在SHOW INNODB STATUS的显示内容中，会有详细的当前锁等待的信息，包括表名、锁类型、锁定记录的情况等，便于进行进一步的分析和问题的确定。打开监视器以后，默认情况下每15秒会向日志中记录监控的内容，如果长时间打开会导致.err文件变得非常的巨大，所以用户在确认问题原因之后，要记得删除监控表以关闭监视器，或者通过使用“--console”选项来启动服务器以关闭写日志文件。
InnoDB的行锁模式及加锁方法
InnoDB实现了以下两种类型的行锁。
  共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
  排他锁（X)：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。
另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。
  意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
  意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。
上述锁模式的兼容情况具体如表20-6所示。

 如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。
意向锁是InnoDB自动加的，不需用户干预。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁；事务可以通过以下语句显示给记录集加共享锁或排他锁。
  共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
  排他锁（X)：SELECT * FROM table_name WHERE ... FOR UPDATE。
用SELECT ... IN SHARE MODE获得共享锁，主要用在需要数据依存关系时来确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT... FOR UPDATE方式获得排他锁。
在如表20-7所示的例子中，使用了SELECT ... IN SHARE MODE加锁后再更新记录，看看会出现什么情况，其中actor表的actor_id字段为主键。



当使用SELECT...FOR UPDATE加锁后再更新记录，出现如表20-8所示的情况。




InnoDB行锁实现方式
InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。
（1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。在如表20-9所示的例子中，开始tab_no_index表没有索引：

Java代码  

  1. mysql> create table tab_no_index(id int,name varchar(10)) engine=innodb;  
  2. Query OK, 0 rows affected (0.15 sec)  
  3. mysql> insert into tab_no_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');  
  4. Query OK, 4 rows affected (0.00 sec)  
  5. Records: 4  Duplicates: 0  Warnings: 0  

 表20-9               InnoDB存储引擎的表在不使用索引时使用表锁例子 


在如表20 -9所示的例子中，看起来session_1只给一行加了排他锁，但session_2在请求其他行的排他锁时，却出现了锁等待！原因就是在没有索引的情况下，InnoDB只能使用表锁。当我们给其增加一个索引后，InnoDB就只锁定了符合条件的行，如表20-10所示。
创建tab_with_index表，id字段有普通索引：

Java代码  

  1. mysql> create table tab_with_index(id int,name varchar(10)) engine=innodb;  
  2. Query OK, 0 rows affected (0.15 sec)  
  3. mysql> alter table tab_with_index add index id(id);  
  4. Query OK, 4 rows affected (0.24 sec)  
  5. Records: 4  Duplicates: 0  Warnings: 0  

  

（2）由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。应用设 计的时候要注意这一点。在如表20-11所示的例子中，表tab_with_index的id字段有索引，name字段没有索引

Java代码  

  1. mysql> alter table tab_with_index drop index name;  
  2. Query OK, 4 rows affected (0.22 sec)  
  3. Records: 4  Duplicates: 0  Warnings: 0  
  4. mysql> insert into tab_with_index  values(1,'4');  
  5. Query OK, 1 row affected (0.00 sec)  
  6. mysql> select * from tab_with_index where id = 1;  
  7. +------+------+  
  8. | id   | name |  
  9. +------+------+  
  10. | 1    | 1    |  
  11. | 1    | 4    |  
  12. +------+------+  
  13. 2 rows in set (0.00 sec)  


 （3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。
在如表20-12所示的例子中，表tab_with_index的id字段有主键索引，name字段有普通索引：

Java代码  

  1. mysql> alter table tab_with_index add index name(name);  
  2. Query OK, 5 rows affected (0.23 sec)  
  3. Records: 5  Duplicates: 0  Warnings: 0  

 表20-12                                  InnoDB存储引擎的表使用不同索引的阻塞例子


 （4）即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。关于MySQL在什么情况下不使用索引的详细讨论，参见本章“索引问题”一节的介绍。
在下面的例子中，检索值的数据类型与索引字段不同，虽然MySQL能够进行数据类型转换，但却不会使用索引，从而导致InnoDB使用表锁。通过用explain检查两条SQL的执行计划，我们可以清楚地看到了这一点。
例子中tab_with_index表的name字段有索引，但是name字段是varchar类型的，如果where条件中不是和varchar类型进行比较，则会对name进行类型转换，而执行的全表扫描。

Java代码  

  1. mysql> alter table tab_no_index add index name(name);  
  2. Query OK, 4 rows affected (8.06 sec)  
  3. Records: 4  Duplicates: 0  Warnings: 0  
  4. mysql> explain select * from tab_with_index where name = 1 \G  
  5. *************************** 1. row ***************************  
  6.            id: 1  
  7.   select_type: SIMPLE  
  8.         table: tab_with_index  
  9.          type: ALL  
  10. possible_keys: name  
  11.           key: NULL  
  12.       key_len: NULL  
  13.           ref: NULL  
  14.          rows: 4  
  15.         Extra: Using where  
  16. 1 row in set (0.00 sec)  
  17. mysql> explain select * from tab_with_index where name = '1' \G  
  18. *************************** 1. row ***************************  
  19.            id: 1  
  20.   select_type: SIMPLE  
  21.         table: tab_with_index  
  22.          type: ref  
  23. possible_keys: name  
  24.           key: name  
  25.       key_len: 23  
  26.           ref: const  
  27.          rows: 1  
  28.         Extra: Using where  
  29. 1 row in set (0.00 sec)  

 间隙锁（Next-Key锁）

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的 索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁 （Next-Key锁）。

举例来说，假如emp表中只有101条记录，其empid的值分别是 1,2,...,100,101，下面的SQL：

Select * from  emp where empid > 100 for update;

是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。

InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，要是不使 用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另外一方面，是为了满足其恢复和复制的需 要。有关其恢复和复制对锁机制的影响，以及不同隔离级别下InnoDB使用间隙锁的情况，在后续的章节中会做进一步介绍。

很显然，在使用范围条件检索并锁定记录时，InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。

还要特别说明的是，InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁！

在如表20-13所示的例子中，假如emp表中只有101条记录，其empid的值分别是1,2,......,100,101。

恢复和复制的需要，对InnoDB锁机制的影响

MySQL通过BINLOG录执行成功的INSERT、UPDATE、DELETE等更新数据的SQL语句， 并由此实现MySQL数据库的恢复和主从复制（可以参见本书“管理篇”的介绍）。MySQL的恢复机制（复制其实就是在Slave Mysql不断做基于BINLOG的恢复）有以下特点。

l  一是MySQL的恢复是SQL语句级的，也就是重新执行BINLOG中的SQL语句。这与Oracle数据库不同，Oracle是基于数据库文件块的。

l  二是MySQL的Binlog是按照事务提交的先后顺序记录的，恢复也是按这个顺序进行的。这点也与Oralce不同，Oracle是按照系统更新号 （System Change Number，SCN）来恢复数据的，每个事务开始时，Oracle都会分配一个全局唯一的SCN，SCN的顺序与事务开始的时间顺序是一致的。

从上面两点可知，MySQL的恢复 机制要求：在一个事务未提交前，其他并发事务不能插入满足其锁定条件的任何记录，也就是不允许出现幻读，这已经超过了ISO/ANSI SQL92“可重复读”隔离级别的要求，实际上是要求事务要串行化。这也是许多情况下，InnoDB要用到间隙锁的原因，比如在用范围条件更新记录时，无 论在Read Commited或是Repeatable Read隔离级别下，InnoDB都要使用间隙锁，但这并不是隔离级别要求的，有关InnoDB在不同隔离级别下加锁的差异在下一小节还会介绍。

另外，对于“insert  into target_tab select * from source_tab where ...”和“create  table new_tab ...select ... From  source_tab where ...(CTAS)”这种SQL语句，用户并没有对source_tab做任何更新操作，但MySQL对这种SQL语句做了特别处理。先来看如表20-14的例子。


 在上面的例子中，只是简单地读 source_tab表的数据，相当于执行一个普通的SELECT语句，用一致性读就可以了。ORACLE正是这么做的，它通过MVCC技术实现的多版本 数据来实现一致性读，不需要给source_tab加任何锁。我们知道InnoDB也实现了多版本数据，对普通的SELECT一致性读，也不需要加任何 锁；但这里InnoDB却给source_tab加了共享锁，并没有使用多版本数据一致性读技术！

时间： 2024-09-22 01:58:24

MYSQL InnoDB表锁的相关文章

mysql-MYSQL INNODB表锁和行锁的问题

问题描述 MYSQL INNODB表锁和行锁的问题 Id是主键.以下语句分别是行锁还是表锁? 第一句:update Table set X=1 where Id IN (1,2,4,7); 第二句:update Table set X=1 where Id Between 1 AND 10; 第三句:update Table set X=1 where Id>=1 AND Id<100; 解决方案 这些都是行锁,只有lock table语句innodb才会申请表锁

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 InnoDB引擎锁机制解决死锁问题

最近,在项目开发过程中,碰到了数据库死锁问题,在解决问题的过程中,笔者对MySQL InnoDB引擎锁机制的理解逐步加深. 案例如下: 在使用Show innodb status检查引擎状态时,发现了死锁问题: *** (1) TRANSACTION: TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OS thread id 278546 starting index read mysql tables in use 1, loc

RDS for MySQL InnoDB 行锁等待和锁等待超时的处理

RDS for MySQL InnoDB 行锁等待和锁等待超时的处理   1. InnoDB 引擎表行锁等待和等待超时发生的场景 2.InnoDB 引擎行锁等待情况的处理 2.1 InnoDB 行锁等待超时参数 innodb_lock_wait_timeout 2.2 大量行锁等待和行锁等待超时的处理 1. InnoDB 引擎表行锁等待和等待超时发生的场景 当一个 RDS for MySQL 连接会话等待另外一个会话持有的互斥行锁时,会发生 InnoDB 引擎表行锁等待情况. 通常情况下,持有该

Mysql innodb 间隙锁

前段时间系统老是出现insert死锁,很是纠结.经过排查发现是间隙锁!间隙锁是innodb中行锁的一种, 但是这种锁锁住的却不止一行数据,他锁住的是多行,是一个数据范围.间隙锁的主要作用是为了防止出现幻读,但是它会把锁定范围扩大,有时候也会给我们带来麻烦,我们就遇到了. 在数据库参数中, 控制间隙锁的参数是:innodb_locks_unsafe_for_binlog, 这个参数默认值是OFF, 也就是启用间隙锁, 他是一个bool值, 当值为true时表示disable间隙锁.那为了防止间隙锁

MYSQL MyISAM表锁

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

MySQL Innodb表导致死锁日志情况分析与归纳_Mysql

案例描述在定时脚本运行过程中,发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志.两个sql语句如下:(1)insert into backup_table select * from source_table(2)DELETE FROM source_table WHERE Id>5 AND titleWeight<32768 AND joinTime<'$daysago_1week'teamUser表的表结构如下:PRIMARY

MySQL InnoDB表空间及日志文件简介

MySQL一个显著的特点是其可插拔的存储引擎,因此MySQL文件分为两种:一种是MySQL服务器本身的文件(主要是一 些日志文件,如错误日志.二进制日志等),所有的存储引擎共享:另一种是和具体存储引擎相关的文件.本文主要介 绍和InnoDB存储引擎相关的文件(数据+日志),至于MySQL服务器本身的日志文件,可以参考<[MySQL] 日志文件概述 >. InnoDB表空间文件 InnoDB在很多方面和Oracle非常像,它的数据也是按表空间存储的,表空间是一个在逻辑上为整体的存储块,默认情 况

常见 mysql innodb 表错误

修复 mysql 过程中 mysql> check table itv_back.itv_score1; +---------------------+-------+----------+----------------------------------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +---------------------