MySQL中表锁和行锁机制浅析(源码篇)
[var]
众所周知，MySQL的存储引擎有MyISAM和InnoDB，锁粒度分别是表锁和行锁。
后者的出现从某种程度上是弥补前者的不足，比如：MyISAM不支持事务，InnoDB支持事务。表锁虽然开销小，锁表快，但高并发下性能低。行锁虽然开销大，锁表慢，但高并发下相比之下性能更高。事务和行锁都是在确保数据准确的基础上提高并发的处理能力。下面分别进行介绍：
[var]
行锁的劣势：
- 开销大；
- 加锁慢；
- 会出现死锁
行锁的优势：
- 锁的粒度小，发生锁冲突的概率低；
- 处理并发的能力强
加锁的方式：
- 自动加锁：对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁；
- 无锁：对于普通SELECT语句，InnoDB不会加任何锁；当然我们也可以显示的加锁：
- 共享锁：select * from tableName where … + lock in share more
- 排他锁：select * from tableName where … + for update
InnoDB和MyISAM的最大不同点有两个：
- InnoDB支持事务(transaction)；
- 默认采用行级锁。
加锁可以保证事务的一致性，下面我们来学习一下MySQL的事务知识.
MySQL 事务属性
事务是由一组SQL语句组成的逻辑处理单元，事务具有ACID属性。 原子性（Atomicity）：事务是一个原子操作单元。在当时原子是不可分割的最小元素，其对数据的修改，要么全部成功，要么全部都不成功。 一致性（Consistent）：事务开始到结束的时间段内，数据都必须保持一致状态。 隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的"独立"环境执行。 持久性（Durable）：事务完成后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。
事务常见问题
更新丢失（Lost Update） 原因：当多个事务选择同一行操作，并且都是基于最初选定的值，由于每个事务都不知道其他事务的存在，就会发生更新覆盖的问题。类比github提交冲突。
脏读（Dirty Reads） 原因：事务A读取了事务B已经修改但尚未提交的数据。若事务B回滚数据，事务A的数据存在不一致性的问题。
不可重复读（Non-Repeatable Reads） 原因：事务A第一次读取最初数据，第二次读取事务B已经提交的修改或删除数据。导致两次读取数据不一致。不符合事务的隔离性。
幻读（Phantom Reads） 原因：事务A根据相同条件第二次查询到事务B提交的新增数据，两次数据结果集不一致。不符合事务的隔离性。
幻读和脏读有点类似 脏读是事务B里面修改了数据， 幻读是事务B里面新增了数据。
事务的隔离级别
数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大。这是因为事务隔离实质上是将事务在一定程度上"串行"进行，这显然与"并发"是矛盾的。根据自己的业务逻辑，权衡能接受的最大副作用。从而平衡了"隔离" 和 "并发"的问题。MySQL默认隔离级别是可重复读。 脏读，不可重复读，幻读，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。
| 隔离级别 | 读数据一致性 | 脏读 | 不可重复 读 | 幻读 |
+——————————+———————+————–+————–+————–+
| 未提交读(Read uncommitted) | 最低级别 | 是 | 是 | 是 |
+——————————+———————+————–+————–+————–+
| 已提交读(Read committed) | 语句级 | 否 | 是 | 是 |
+——————————+———————+————–+————–+————–+
| 可重复读(Repeatable read) | 事务级 | 否 | 否 | 是 |
+——————————+———————+————–+————–+————–+
| 可序列化(Serializable) | 最高级别，事务级 | 否 | 否 | 否 |
+——————————+———————+————–+————–+————–+
查看当前数据库的事务隔离级别：show variables like 'tx_isolation';
+—————+—————–+
| Variable_name | Value |
+—————+—————–+
| tx_isolation | REPEATABLE-READ |
+—————+—————–+
间隙锁
当我们用范围条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做"间隙(GAP)"。InnoDB也会对这个"间隙"加锁，这种锁机制就是所谓的间隙锁(Next-Key锁)。
mysql> update innodb_lock set k=66 where id >=6;
Query OK, 1 row affected (0.63 sec)
mysql> commit;
Transaction-B
mysql> insert into innodb_lock (id,k,v) values(7,’7′,’7000′);
Query OK, 1 row affected (18.99 sec)
危害(坑)：若执行的条件是范围过大，则InnoDB会将整个范围内所有的索引键值全部锁定，很容易对性能造成影响。
排他锁
排他锁，也称写锁，独占锁，当前写操作没有完成前，它会阻断其他写锁和读锁。
mysql> set autocommit=0;
mysql> select * from innodb_lock where id=4 for update;
+—-+——+——+
| id | k | v |
+—-+——+——+
| 4 | 4 | 4000 |
+—-+——+——+
1 row in set (0.00 sec)
mysql> update innodb_lock set v=’4001′ where id=4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> commit;
Query OK, 0 rows affected (0.04 sec)
# Transaction_B
mysql> select * from innodb_lock where id=4 for update;
+—-+——+——+
| id | k | v |
+—-+——+——+
| 4 | 4 | 4001 |
+—-+——+——+
1 row in set (9.53 sec)
共享锁
共享锁，也称读锁，多用于判断数据是否存在，多个读操作可以同时进行而不会互相影响。当如果事务对读锁进行修改操作，很可能会造成死锁。如下图所示。
mysql> set autocommit=0;
mysql> select * from innodb_lock where id=4 lock in share mode;
+—-+——+——+
| id | k | v |
+—-+——+——+
| 4 | 4 | 4001 |
+—-+——+——+
1 row in set (0.00 sec)
mysql> update innodb_lock set v=’4002′ where id=4;
Query OK, 1 row affected (31.29 sec)
Rows matched: 1 Changed: 1 Warnings: 0
# Transaction_B
mysql> set autocommit=0;
mysql> select * from innodb_lock where id=4 lock in share mode;
+—-+——+——+
| id | k | v |
+—-+——+——+
| 4 | 4 | 4001 |
+—-+——+——+
1 row in set (0.00 sec)
mysql> update innodb_lock set v=’4002′ where id=4;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
分析行锁定
通过检查InnoDB_row_lock 状态变量分析系统上的行锁的争夺情况 show status like 'innodb_row_lock%'
+——————————-+——-+
| Variable_name | Value |
+——————————-+——-+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 0 |
| Innodb_row_lock_time_avg | 0 |
| Innodb_row_lock_time_max | 0 |
| Innodb_row_lock_waits | 0 |
+——————————-+——-+
innodb_row_lock_current_waits: 当前正在等待锁定的数量 innodb_row_lock_time: 从系统启动到现在锁定总时间长度；非常重要的参数， innodb_row_lock_time_avg: 每次等待所花平均时间；非常重要的参数， innodb_row_lock_time_max: 从系统启动到现在等待最常的一次所花的时间； innodb_row_lock_waits: 系统启动后到现在总共等待的次数；非常重要的参数。直接决定优化的方向和策略。
行锁优化
1 尽可能让所有数据检索都通过索引来完成，避免无索引行或索引失效导致行锁升级为表锁。 2 尽可能避免间隙锁带来的性能下降，减少或使用合理的检索范围。 3 尽可能减少事务的粒度，比如控制事务大小，而从减少锁定资源量和时间长度，从而减少锁的竞争等，提供性能。 4 尽可能低级别事务隔离，隔离级别越高，并发的处理能力越低。
[var]
表锁的优势：开销小；加锁快；无死锁 表锁的劣势：锁粒度大，发生锁冲突的概率高，并发处理能力低 加锁的方式：自动加锁。查询操作（SELECT），会自动给涉及的所有表加读锁，更新操作（UPDATE、DELETE、INSERT），会自动给涉及的表加写锁。也可以显示加锁： 共享读锁：lock table tableName read; 独占写锁：lock table tableName write; 批量解锁：unlock tables;
共享读锁
对MyISAM表的读操作（加读锁），不会阻塞其他进程对同一表的读操作，但会阻塞对同一表的写操作。只有当读锁释放后，才能执行其他进程的写操作。在锁释放前不能取其他表。
mysql> lock table myisam_lock read;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from myisam_lock;
9 rows in set (0.00 sec)
mysql> select * from innodb_lock;
ERROR 1100 (HY000): Table ‘innodb_lock’ was not locked with LOCK TABLES
mysql> update myisam_lock set v=’1001′ where k=’1′;
ERROR 1099 (HY000): Table ‘myisam_lock’ was locked with a READ lock and can’t be updated
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)
Transaction-B
mysql> select * from myisam_lock;
9 rows in set (0.00 sec)
mysql> select * from innodb_lock;
8 rows in set (0.01 sec)
mysql> update myisam_lock set v=’1001′ where k=’1′;
Query OK, 1 row affected (18.67 sec)
独占写锁
对MyISAM表的写操作（加写锁），会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其他进程的读写操作。在锁释放前不能写其他表。
mysql> set autocommit=0;
Query OK, 0 rows affected (0.05 sec)
mysql> lock table myisam_lock write;
Query OK, 0 rows affected (0.03 sec)
mysql> update myisam_lock set v=’2001′ where k=’2′;
Query OK, 1 row affected (0.00 sec)
mysql> select * from myisam_lock;
9 rows in set (0.00 sec)
mysql> update innodb_lock set v=’1001′ where k=’1′;
ERROR 1100 (HY000): Table ‘innodb_lock’ was not locked with LOCK TABLES
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)
Transaction-B
mysql> select * from myisam_lock;
9 rows in set (42.83 sec)
总结：表锁，读锁会阻塞写，不会阻塞读。而写锁则会把读写都阻塞。
查看加锁情况
show open tables; 1表示加锁，0表示未加锁。
+———-+————-+——–+————-+
| Database | Table | In_use | Name_locked |
+———-+————-+——–+————-+
| lock | myisam_lock | 1 | 0 |
+———-+————-+——–+————-+
分析表锁定
可以通过检查table_locks_waited 和 table_locks_immediate 状态变量分析系统上的表锁定：show status like 'table_locks%'
+—————————-+——-+
| Variable_name | Value |
+—————————-+——-+
| Table_locks_immediate | 104 |
| Table_locks_waited | 0 |
+—————————-+——-+
table_locks_immediate: 表示立即释放表锁数。 table_locks_waited: 表示需要等待的表锁数。此值越高则说明存在着越严重的表级锁争用情况。
此外，MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主表的存储引擎。因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永久阻塞。
[var]
InnoDB默认采用行锁，在未使用索引字段查询时升级为表锁。MySQL这样设计并不是给你挖坑。它有自己的设计目的。 即便你在条件中使用了索引字段，MySQL会根据自身的执行计划，考虑是否使用索引(所以explain命令中会有possible_key 和 key)。如果MySQL认为全表扫描效率更高，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。
第一种情况：全表更新。事务需要更新大部分或全部数据，且表又比较大。若使用行锁，会导致事务执行效率低，从而可能造成其他事务长时间锁等待和更多的锁冲突。
第二种情况：多表级联。事务涉及多个表，比较复杂的关联查询，很可能引起死锁，造成大量事务回滚。这种情况若能一次性锁定事务涉及的表，从而可以避免死锁、减少数据库因事务回滚带来的开销。
[var]
开销和加锁时间介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发处理能力一般。只需了解一下。
[var]
MyISAM中是不会产生死锁的，因为MyISAM总是一次性获得所需的全部锁，要么全部满足，要么全部等待。而在InnoDB中，锁是逐步获得的，就造成了死锁的可能。
在MySQL中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql语句操作了主键索引，MySQL就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。 在UPDATE、DELETE操作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-key locking。
当两个事务同时执行，一个锁住了主键索引，在等待其他相关索引。另一个锁定了非主键索引，在等待主键索引。这样就会发生死锁。
发生死锁后，InnoDB一般都可以检测到，并使一个事务释放锁回退，另一个获取锁完成事务。
有多种方法可以避免死锁，这里只介绍常见的三种
1、如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。
2、在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；
3、对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；
[var]
1 InnoDB 支持表锁和行锁，使用索引作为检索条件修改数据时采用行锁，否则采用表锁。 2 InnoDB 自动给修改操作加锁，给查询操作不自动加锁 3 行锁可能因为未使用索引而升级为表锁，所以除了检查索引是否创建的同时，也需要通过explain执行计划查询索引是否被实际使用。 4 行锁相对于表锁来说，优势在于高并发场景下表现更突出，毕竟锁的粒度小。 5 当表的大部分数据需要被修改，或者是多表复杂关联查询时，建议使用表锁优于行锁。 6 为了保证数据的一致完整性，任何一个数据库都存在锁定机制。锁定机制的优劣直接影响到一个数据库的并发处理能力和性能。
到此这篇关于MySQL中表锁和行锁机制浅析的文章就介绍到这了,更多相关MySQL表锁和行锁机制内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
