视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
MysqlInnoDB行锁实现方式_MySQL
2020-11-09 18:18:11 责编:小采
文档


bitsCN.com
Mysql InnoDB行锁实现方式 InnoDB行锁是通过给索引上的索引项加锁来实现的,这一点MySQL与Oracle不同,后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着:只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁! 在实际应用中,要特别注意InnoDB行锁的这一特性,不然的话,可能导致大量的锁冲突,从而影响并发性能。下面通过一些实际例子来加以说明。(1)在不通过索引条件查询的时候,InnoDB确实使用的是表锁,而不是行锁。 在如表20-9所示的例子中,开始tab_no_index表没有索引:mysql> create table tab_no_index(id int,name varchar(10)) engine=innodb;Query OK, 0 rows affected (0.15 sec)mysql> insert into tab_no_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');Query OK, 4 rows affected (0.00 sec)Records: 4 Duplicates: 0 Warnings: 0表20-9 InnoDB存储引擎的表在不使用索引时使用表锁例子 session_1session_2mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select * from tab_no_index where id = 1 ;+------+------+| id | name |+------+------+| 1 | 1 |+------+------+1 row in set (0.00 sec)mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select * from tab_no_index where id = 2 ;+------+------+| id | name |+------+------+| 2 | 2 |+------+------+1 row in set (0.00 sec)mysql> select * from tab_no_index where id = 1 for update;+------+------+| id | name |+------+------+| 1 | 1 |+------+------+1 row in set (0.00 sec) mysql> select * from tab_no_index where id = 2 for update;等待在如表20-9所示的例子中,看起来session_1只给一行加了排他锁,但session_2在请求其他行的排他锁时,却出现了锁等待!原因就是在没有索引的情况下,InnoDB只能使用表锁。当我们给其增加一个索引后,InnoDB就只锁定了符合条件的行,如表20-10所示。 创建tab_with_index表,id字段有普通索引: mysql> create table tab_with_index(id int,name varchar(10)) engine=innodb;Query OK, 0 rows affected (0.15 sec)mysql> alter table tab_with_index add index id(id);Query OK, 4 rows affected (0.24 sec)Records: 4 Duplicates: 0 Warnings: 0表20-10 InnoDB存储引擎的表在使用索引时使用行锁例子 session_1session_2mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select * from tab_with_index where id = 1 ;+------+------+| id | name |+------+------+| 1 | 1 |+------+------+1 row in set (0.00 sec)mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select * from tab_with_index where id = 2 ;+------+------+| id | name |+------+------+| 2 | 2 |+------+------+1 row in set (0.00 sec)mysql> select * from tab_with_index where id = 1 for update;+------+------+| id | name |+------+------+| 1 | 1 |+------+------+1 row in set (0.00 sec) mysql> select * from tab_with_index where id = 2 for update;+------+------+| id | name |+------+------+| 2 | 2 |+------+------+1 row in set (0.00 sec)(2)由于MySQL的行锁是针对索引加的锁,不是针对记录加的锁,所以虽然是访问不同行的记录,但是如果是使用相同的索引键,是会出现锁冲突的。应用设计的时候要注意这一点。 在如表20-11所示的例子中,表tab_with_index的id字段有索引,name字段没有索引: mysql> alter table tab_with_index drop index name;Query OK, 4 rows affected (0.22 sec)Records: 4 Duplicates: 0 Warnings: 0mysql> insert into tab_with_index values(1,'4');Query OK, 1 row affected (0.00 sec)mysql> select * from tab_with_index where id = 1;+------+------+| id | name |+------+------+| 1 | 1 || 1 | 4 |+------+------+2 rows in set (0.00 sec)表20-11 InnoDB存储引擎使用相同索引键的阻塞例子 session_1session_2mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select * from tab_with_index where id = 1 and name = '1' for update;+------+------+| id | name |+------+------+| 1 | 1 |+------+------+1 row in set (0.00 sec) 虽然session_2访问的是和session_1不同的记录,但是因为使用了相同的索引,所以需要等待锁:mysql> select * from tab_with_index where id = 1 and name = '4' for update;等待(3)当表有多个索引的时候,不同的事务可以使用不同的索引锁定不同的行,另外,不论是使用主键索引、唯一索引或普通索引,InnoDB都会使用行锁来对数据加锁。 在如表20-12所示的例子中,表tab_with_index的id字段有主键索引,name字段有普通索引: mysql> alter table tab_with_index add index name(name);Query OK, 5 rows affected (0.23 sec)Records: 5 Duplicates: 0 Warnings: 0表20-12 InnoDB存储引擎的表使用不同索引的阻塞例子 · session_1· session_2mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> set autocommit=0;Query OK, 0 rows affected (0.00 sec)mysql> select * from tab_with_index where id = 1 for update;+------+------+| id | name |+------+------+| 1 | 1 || 1 | 4 |+------+------+2 rows in set (0.00 sec) Session_2使用name的索引访问记录,因为记录没有被索引,所以可以获得锁:mysql> select * from tab_with_index where name = '2' for update;+------+------+| id | name |+------+------+| 2 | 2 |+------+------+1 row in set (0.00 sec) 由于访问的记录已经被session_1锁定,所以等待获得锁。:mysql> select * from tab_with_index where name = '4' for update;(4)即便在条件中使用了索引字段,但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的,如果MySQL认为全表扫描效率更高,比如对一些很小的表,它就不会使用索引,这种情况下InnoDB将使用表锁,而不是行锁。因此,在分析锁冲突时,别忘了检查SQL的执行计划,以确认是否真正使用了索引。关于MySQL在什么情况下不使用索引的详细讨论,参见本章“索引问题”一节的介绍。 在下面的例子中,检索值的数据类型与索引字段不同,虽然MySQL能够进行数据类型转换,但却不会使用索引,从而导致InnoDB使用表锁。通过用explain检查两条SQL的执行计划,我们可以清楚地看到了这一点。 例子中tab_with_index表的name字段有索引,但是name字段是varchar类型的,如果where条件中不是和varchar类型进行比较,则会对name进行类型转换,而执行的全表扫描。 mysql> alter table tab_no_index add index name(name);Query OK, 4 rows affected (8.06 sec)Records: 4 Duplicates: 0 Warnings: 0mysql> explain select * from tab_with_index where name = 1 /G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: tab_with_indextype: ALLpossible_keys: namekey: NULLkey_len: NULLref: NULLrows: 4Extra: Using where1 row in set (0.00 sec)mysql> explain select * from tab_with_index where name = '1' /G*************************** 1. row ***************************id: 1 select_type: SIMPLEtable: tab_with_indextype: refpossible_keys: namekey: namekey_len: 23ref: constrows: 1Extra: Using where1 row in set (0.00 sec) 来自CS程序员之窗 bitsCN.com

下载本文
显示全文
专题