MySQL 避免行锁升级为表锁——使用高效的索引

　　众所周知，MySQL 的 InnoDB 存储引擎支持事务，默认是行锁。得益于这些特性，数据库支持高并发。若是 InnoDB 更新数据使用的不是行锁，而是表锁呢？是的，InnoDB 其实很容易就升级为表锁，届时并发性将大打折扣了。

　　通过我操做验证，得出行锁升级为表锁的缘由之一是： SQL 语句中未使用到索引，或者说使用的索引未被数据库承认（至关于没有使用索引）。

　　我相信，MySQL InnoDB 存储引擎引起表锁的缘由确定不止一个因素，针对其解决方法也不是只有一种。

　　【掘金】上另外一位做者【Blink-前端】，提出行锁升级为表锁与 事务的隔离级别 有关，并给出了事例。固然，我赞成这个说法，由于事务的隔离性是靠加锁来实现的，而加锁势必会影响并发。本篇只针对 索引影响并发 做出说明，并特别但愿有朋友能提出质疑并给出独特看法，万分感谢。

普通索引

　　既然谈及索引是影响并发的决定因素之一，那咱们就来了解一下索引这位主角。

　　经常使用的索引有三类：主键、惟一索引、普通索引。主键 不禁分说，自带最高效的索引属性；惟一索引 指的是该属性值重复率为0，通常可做为业务主键，例如学号；普通索引 与前者不一样的是，属性值的重复率大于0，不能做为惟一指定条件，例如学生姓名。接下来我要说明是 “普通索引对并发的影响”。

　　为何我会想到 “普通索引对并发有影响”？这源自【掘金】微信群抛出的一个问题：

mysql 5.6 在 update 和 delete 的时候，where 条件若是不存在索引字段，那么这个事务是否会致使表锁？

　　有人回答：

只有主键和惟一索引才是行锁，普通索引是表锁。

　　我针对 “普通索引是表锁” 进行了验证，结果发现普通索引并不必定会引起表锁，在普通索引中，是否引起表锁取决于普通索引的高效程度。

　　上文说起的“高效”是相对主键和惟一索引而言，也许“高效”并非一个很好的解释，明白在通常i状况下，“普通索引”效率低于其余二者便可。

属性值重复率高

　　为了突出效果，我将“普通索引”创建在一个“值重复率”高的属性下。以相对极端的方式，扩大对结果的影响。

　　我会建立一张“分数等级表”，属性有“id”、“score（分数）”、“level（等级）”，模拟一个半自动的业务——“分数”已被自动导入，而“等级”须要手工更新。

　　操做步骤以下：

1. 取消 MySQL 的 事务自动提交
2. 建表，id自增，并给“score（分数）”建立普通索引
3. 插入分数值，等级为 null
4. 开启两个事务 session_一、session_2，两个事务以“score”为条件指定不一样值，锁定数据
5. session_1 和 session_2 前后更新各自事务锁定内容的“level”
6. 观察数据库对两个事务的响应

　　取消 事务自动提交：

mysql> set autocommit = off;
Query OK, 0 rows affected (0.02 sec)

mysql> show variables like "autocommit";
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| autocommit               | OFF   |
+--------------------------+-------+
1 rows in set (0.01 sec)复制代码

　　建表、建立索引、插入数据：

DROP TABLE IF EXISTS `test1`;
CREATE TABLE `test1` (
`ID`  int(5) NOT NULL AUTO_INCREMENT ,
`SCORE`  int(3) NOT NULL ,
`LEVEL`  int(2) NULL DEFAULT NULL ,
PRIMARY KEY (`ID`)
)ENGINE=InnoDB DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci;

ALTER TABLE `test2` ADD INDEX index_name ( `SCORE` );

INSERT INTO `test1`(`SCORE`) VALUE (100);
……
INSERT INTO `test1`(`SCORE`) VALUE (0);
……复制代码

　　"SCORE" 属性的“值重复率”奇高，达到了 50%，剑走偏锋：

mysql> select * from test1;
+----+-------+-------+
| ID | SCORE | LEVEL |
+----+-------+-------+
|  1 |   100 | NULL  |
|  2 |     0 | NULL  |
|  5 |   100 | NULL  |
|  6 |   100 | NULL  |
|  7 |   100 | NULL  |
|  8 |   100 | NULL  |
|  9 |   100 | NULL  |
| 10 |   100 | NULL  |
| 11 |   100 | NULL  |
| 12 |   100 | NULL  |
| 13 |   100 | NULL  |
| 14 |     0 | NULL  |
| 15 |     0 | NULL  |
| 16 |     0 | NULL  |
| 17 |     0 | NULL  |
| 18 |     0 | NULL  |
| 19 |     0 | NULL  |
| 20 |     0 | NULL  |
| 21 |     0 | NULL  |
| 22 |     0 | NULL  |
| 23 |     0 | NULL  |
| 24 |   100 | NULL  |
| 25 |     0 | NULL  |
| 26 |   100 | NULL  |
| 27 |     0 | NULL  |
+----+-------+-------+
25 rows in set复制代码

　　开启两个事务（一个窗口对应一个事务），并选定数据：

-- SESSION_1，选定 SCORE = 100 的数据
mysql> BEGIN;
SELECT t.* FROM `test1` t WHERE t.`SCORE` = 100 FOR UPDATE;
Query OK, 0 rows affected

+----+-------+-------+
| ID | SCORE | LEVEL |
+----+-------+-------+
|  1 |   100 | NULL  |
|  5 |   100 | NULL  |
|  6 |   100 | NULL  |
|  7 |   100 | NULL  |
|  8 |   100 | NULL  |
|  9 |   100 | NULL  |
| 10 |   100 | NULL  |
| 11 |   100 | NULL  |
| 12 |   100 | NULL  |
| 13 |   100 | NULL  |
| 24 |   100 | NULL  |
| 26 |   100 | NULL  |
+----+-------+-------+
12 rows in set复制代码

　　再打开一个窗口：

-- SESSION_2，选定 SCORE = 0 的数据
mysql> BEGIN;
SELECT t.* FROM `test1` t WHERE t.`SCORE` = 0 FOR UPDATE;
Query OK, 0 rows affected

+----+-------+-------+
| ID | SCORE | LEVEL |
+----+-------+-------+
|  2 |     0 | NULL  |
| 14 |     0 | NULL  |
| 15 |     0 | NULL  |
| 16 |     0 | NULL  |
| 17 |     0 | NULL  |
| 18 |     0 | NULL  |
| 19 |     0 | NULL  |
| 20 |     0 | NULL  |
| 21 |     0 | NULL  |
| 22 |     0 | NULL  |
| 23 |     0 | NULL  |
| 25 |     0 | NULL  |
| 27 |     0 | NULL  |
+----+-------+-------+
13 rows in set复制代码

　　session_1 窗口，更新“LEVEL”失败：

mysql> UPDATE `test1` SET `LEVEL` = 1 WHERE `SCORE` = 100;
1205 - Lock wait timeout exceeded; try restarting transaction复制代码

　　在以前的操做中，session_1 选择了 `SCORE` = 100 的数据，session_2 选择了 `SCORE` = 0 的数据，看似两个事务井水不犯河水，可是在 session_1 事务中更新本身锁定的数据失败，只能说明在此时引起了表锁。别着急，刚刚走向了一个极端——索引属性值重复性奇高，接下来走向另外一个极端。 　　

属性值重复率低

　　仍是同一张表，将数据删除只剩下两条，“SCORE” 的 “值重复率” 为 0：

mysql> delete from test1 where id > 2;
Query OK, 23 rows affected

mysql> select * from test1;
+----+-------+-------+
| ID | SCORE | LEVEL |
+----+-------+-------+
|  1 |   100 | NULL  |
|  2 |     0 | NULL  |
+----+-------+-------+
2 rows in set复制代码

　　关闭两个事务操做窗口，从新开启 session_1 和 session_2，并选择各自须要的数据：

-- SESSION_1，选定 SCORE = 100 的数据
mysql> BEGIN;
SELECT t.* FROM `test1` t WHERE t.`SCORE` = 100 FOR UPDATE;
Query OK, 0 rows affected

+----+-------+-------+
| ID | SCORE | LEVEL |
+----+-------+-------+
|  1 |   100 | NULL  |
+----+-------+-------+
1 row in set

-- -----------------新窗口----------------- --

-- SESSION_2，选定 SCORE = 0 的数据
mysql> BEGIN;
SELECT t.* FROM `test1` t WHERE t.`SCORE` = 0 FOR UPDATE;
Query OK, 0 rows affected

+----+-------+-------+
| ID | SCORE | LEVEL |
+----+-------+-------+
|  2 |     0 | NULL  |
+----+-------+-------+
1 row in set复制代码

　　session_1 更新数据成功：

mysql> UPDATE `test1` SET `LEVEL` = 1 WHERE `SCORE` = 100;
Query OK, 1 row affected
Rows matched: 1  Changed: 1  Warnings: 0复制代码

　　相同的表结构，相同的操做，两个不一样的结果让人出乎意料。第一个结果让人以为“普通索引”引起表锁，第二个结果推翻了前者，两个操做中，惟一不一样的是索引属性的“值重复率”。根据 单一变量 证实法，能够得出结论：当“值重复率”低时，甚至接近主键或者惟一索引的效果，“普通索引”依然是行锁；当“值重复率”高时，MySQL 不会把这个“普通索引”当作索引，即形成了一个没有索引的 SQL，此时引起表锁。

小结

　　索引不是越多越好，索引存在一个和这个表相关的文件里，占用硬盘空间，宁缺勿滥，每一个表都有主键（id），操做能使用主键尽可能使用主键。

　　同 JVM 自动优化 java 代码同样，MySQL 也具备自动优化 SQL 的功能。低效的索引将被忽略，这也就倒逼开发者使用正确且高效的索引。

　　转载请注明出处：zhoupq.com/MySQL-%E9%8…