mysql的存储引擎与锁
Posted piwenfei
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了mysql的存储引擎与锁相关的知识，希望对你有一定的参考价值。
一、背景知识
1、锁是计算机协调多个进程或线程并发访问某一资源的机制。
A、锁分类。
| 共享锁（读锁）：在锁定期间，多个用户可以读取同一个资源，读取过程中数据不会发生变化。
| 排他锁（写锁）：在锁定期间，只允许一个用户写入数据，其它用户的读取，写入等操作都会被拒绝。
B、锁颗粒
| 表锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
| 行锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
| 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
2、事务是由一组SQL语句组成的逻辑处理单元。
A、事务（Transaction）及其ACID属性。
| 原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
| 一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
| 隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
| 持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。
B、事务并发问题
| 更新丢失（Lost Update）：两个或多个事务同时更新一个资源，前面的事务的操作结果会被最后面的事务的操作结果覆盖。
| 脏读（Dirty Reads）：事务A正在更新记录X，事务B读取了记录X，并藉此做进一步处理，事务A更新完毕记录X，此时数据库中的记录X与事务B读到的记录X并不是一致的。那么事务B读取到的就是“脏数据”，此类现象称之为“脏读”。
| 不可重复读（Non-Repeatable Reads）：事务A读取了记录X，然后事务B更新了记录X，然后事务A再次读取记录X。此类情况下，事务A读取的记录X并不一定是相同的。
| 幻读（Phantom Reads）：事务Ａ按相同的查询条件读取已经读取过的记录Ｘ时，发现，事务Ｂ更新的记录Ｙ也符合事务Ａ的查询条件。那么，事务A将会读取到记录Ｙ，而不是记录Ｘ。此类现象称之为“幻读”。
Ｃ、事务隔离解决事务并发问题
| 隔离级别 | 说明 | 脏读 | 不可重复读 | 幻读 |
| Read Uncommitted（读取未提交内容） | 所有事务都可以看到其他未提交事务的执行结果。 | 是 | 是 | 是 |
| Read Committed（读取提交内容） | 一个事务只能看见已经提交事务所做的改变。 | 否 | 是 | 是 |
| Repeatable Read（可重读） | 这是mysql的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。 | 否 | 否 | 是 |
| Serializable（可串行化） | 它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。 | 否 | 否 | 否 |
二、各个存储引擎的特点
| 特点 | MyISAM | InnoDB | Memory | Archive |
| 存储限制 | 256TB | 64TB | 有 | 无 |
| 事务安全 | - | 支持 | - | - |
| 支持索引 | 支持 | 支持 | 支持 | |
| 锁颗粒 | 表锁 | 行锁 | 表锁 | 行锁 |
| 数据压缩 | 支持 | - | - | 支持 |
| 支持外键 | - | 支持 | - | - |
三、MyISAM的锁详解
在我的test数据库中，有两张MyISAM存储引擎的表分别是User与Log。
下面将演示两个线程（A、B）同时操作一张表的情况，开两个ｃｍｄ窗口一个代表Ａ一个代表Ｂ按顺序执行下面的代码。
| 操作 | 说明 | 线程 |
| mysql> show tables; +----------------+ | Tables_in_test | +----------------+ | log | | user | +----------------+ 2 rows in set |
显示所有的表 | A |
| mysql> show status like ‘table%‘; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Table_locks_immediate | 50 | | Table_locks_waited | 0 | +-----------------------+-------+ 2 rows in set (0.00 sec) |
显示表级锁争用情况 | A |
| mysql> lock table log write local; Query OK, 0 rows affected |
给表log显式加上写锁，“local”选项的作用是在满足MyISAM表并发插入条件的情况下，允许其它线程在表尾并发插入记录。 | A |
| mysql> select * from log; |
线程Ｂ读取已经被线程Ａ上了读锁的表ｌｏｇ，可以看到线程Ｂ正在等待。 | Ｂ |
| mysql> select * from user; 1100 - Table ‘user‘ was not locked with LOCK TABLES |
线程Ａ读取了没有被加锁的表Ｕｓｅｒ，可以看到，ｍｙｓｑｌ不让读取。 | Ａ |
| mysql> unlock tables; Query OK, 0 rows affected |
线程A释放了对log表的锁。 | A |
| mysql> show status like ‘table%‘; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Table_locks_immediate | 51 | | Table_locks_waited | 0 | +-----------------------+-------+ 2 rows in set (0.00 sec) |
显示表级锁争用情况，可以看到Table_locks_immediate的值加1了。 | A |
| +--------+-----+---------+-------------+ | log_id | uid | content | create_time | +--------+-----+---------+-------------+ | 1 | 2 | 呵呵 | 10 | | 2 | 2 | 哈哈 | 20 | +--------+-----+---------+-------------+ 2 rows in set (5 min 47.34 sec) |
线程B读取到了log的数据。 | B |
1、总结
| MyISAM，在默认情况下会自动加锁，并不需要显式加锁。
| MyISAM总是一次获得SQL语句所需要的全部锁。这也正是MyISAM表不会出现死锁（Deadlock Free）的原因。其它未加锁的表，并不允许操作。
| MyISAM加的是表级锁。
| 当线程Ａ与线程Ｂ同时要给某个表上读锁与写锁的时候，MyISAM默认让线程Ｂ先上写锁。大量的读与写操作并存的时候，写操作可能会一直得到写锁，导致读操作处于阻塞状态。
2、并发插入调度
MyISAM存储引擎有一个系统变量concurrent_insert，专门用以控制其并发插入的行为，其值分别可以为0、1或2。
| 当concurrent_insert设置为0时，不允许并发插入。
| 当concurrent_insert设置为1时，如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录。这也是MySQL的默认设置。
| 当concurrent_insert设置为2时，无论MyISAM表中有没有空洞，都允许在表尾并发插入记录。
3、MyISAM的锁调度
| 通过指定启动参数 low-priority-updates，使MyISAM引擎默认给予读请求以优先的权利。
| 通过执行命令SET LOW_PRIORITY_UPDATES=1，使该连接发出的更新请求优先级降低。
| 通过指定INSERT、UPDATE、DELETE语句的LOW_PRIORITY属性，降低该语句的优先级。
| 给系统变量max_write_lock_count设置一个合适的值，当一个表的读锁达到这个值后，MySQL就暂时将写请求的优先级降低，给读操作一定获得锁的机会。
四、InnoDB的锁详解
在我的test数据库中，有两张InnoDB存储引擎的表分别是User与Log。
下面将演示两个线程（A、B）同时操作一张表的情况，开两个ｃｍｄ窗口一个代表Ａ一个代表Ｂ按顺序执行下面的代码。
第一个表格是，排他锁的实例。
| 操作 | 说明 | 线程 |
| mysql> show tables; +----------------+ | Tables_in_test | +----------------+ | log | | user | +----------------+ 2 rows in set |
显示所有的表 | A |
| mysql> select * from log; +--------+-----+---------+-------------+ | log_id | uid | content | create_time | +--------+-----+---------+-------------+ | 1 | 1 | 呵呵 | 0 | | 2 | 2 | 哈哈 | 0 | +--------+-----+---------+-------------+ 2 rows in set |
显示log表的信息 | A |
| mysql> show status like ‘innodb_row_lock%‘; +-------------------------------+----------+ | Variable_name | Value | +-------------------------------+----------+ | Innodb_row_lock_current_waits | 0 | | Innodb_row_lock_time | 185770 | | Innodb_row_lock_time_avg | 26538 | | Innodb_row_lock_time_max | 51620 | | Innodb_row_lock_waits | 7 | +-------------------------------+----------+ 5 rows in set (0.00 sec) |
查看InnoDB的锁争用情况 | B |
| mysql> start transaction; Query OK, 0 rows affected |
开启事务 | A |
| mysql> update log set create_time=1 where uid=1; Query OK, 1 row affected Rows matched: 1 Changed: 1 Warnings: 0 |
更新uid=1的数据 Select…For Update 语句可以在读取数据的时候就锁定它。 |
A |
| mysql> update log set create_time=2 where uid=2; |
更新uid=2的数据，可以看线程B在等待，因为此时InnoDB加的是表级排他锁。 |
B |
| mysql> commit; Query OK, 0 rows affected |
提交事务 | A |
| mysql> update log set create_time=2 where uid=2; Query OK, 1 row affected (9.69 sec) Rows matched: 1 Changed: 1 Warnings: 0 |
线程B执行update成功 | B |
| mysql> show status like ‘innodb_row_lock%‘; +--------------------------------+---------+ | Variable_name | Value | +--------------------------------+---------+ | Innodb_row_lock_current_waits | 0 | | Innodb_row_lock_time | 196980 | | Innodb_row_lock_time_avg | 24622 | | Innodb_row_lock_time_max | 51620 | | Innodb_row_lock_waits | 8 | +--------------------------------+---------+ 5 rows in set (0.00 sec) |
再次查看InnoDB的锁争用情况 。 如 InnoDB_row_lock_waits 和InnoDB_row_lock_time_avg 的值比较高，则锁的争用情况严重。 |
B |
| mysql> select * from log; +--------+-----+---------+-------------+ | log_id | uid | content | create_time | +--------+-----+---------+-------------+ | 1 | 1 | 呵呵 | 1 | | 2 | 2 | 哈哈 | 2 | +--------+-----+---------+-------------+ 2 rows in set (0.00 sec) |
显示log表的信息 | B |
第二个表格是，共享锁的实例。
| 操作 | 说明 | 线程 |
| mysql> start transaction; Query OK, 0 rows affected (0.00 sec) |
开启事务 | A |
| mysql> start transaction; Query OK, 0 rows affected (0.00 sec) |
开启事务 | B |
| mysql> select * from log where uid=1 lock in share mode; +--------+-----+---------+-------------+ | log_id | uid | content | create_time | +--------+-----+---------+-------------+ | 1 | 1 | 呵呵 | 1 | +--------+-----+---------+-------------+ 1 row in set (0.00 sec) |
线程Ａ取得共享锁 | Ａ |
| mysql> select * from log where uid=1 lock in share mode; +--------+-----+---------+-------------+ | log_id | uid | content | create_time | +--------+-----+---------+-------------+ | 1 | 1 | 呵呵 | 1 | +--------+-----+---------+-------------+ 1 row in set (0.00 sec) |
线程Ｂ取得共享锁 | Ｂ |
| mysql> update log set create_time=1 where uid=1; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction |
线程Ａ更新一条记录，暂时不要去操作下面的步骤，直到出现报错。 由于线程Ｂ的共享锁，导致了线程A无法更新数据。 |
A |
| mysql> update log set create_time=1 where uid=1; Query OK, 0 rows affected (7.82 sec) Rows matched: 1 Changed: 0 Warnings: 0 |
线程Ａ再次更新记录，同时在线程A还在等待的时候，线程B也执行了更新记录。 | A |
| mysql> update log set create_time=1 where uid=1; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
线程B执行更新记录。注意，当线程B执行更新语句的时候，线程B失去了共享锁，线程A获得了排他锁，导致线程B的语句立刻出现了报错。 | B |
| mysql> select * from log where uid=1 lock in share mode; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction |
线程Ｂ再次执行获取共享锁的语句，可以看到，由于线程Ａ已经取得了排他锁，导致线程Ｂ争锁失败。 如果线程Ａ执行ｃｏｍｍｉｔ语句释放排他锁后，线程Ｂ则可以立马获得共享锁。 |
B |
总结：
InnoDB行锁是通过给索引上的索引项加锁来实现的，无索引的情况下，InnoDB将使用表锁！实际应用中，要特别注意此特性。避免大量锁冲突影响并发性能。
以上是关于mysql的存储引擎与锁的主要内容，如果未能解决你的问题，请参考以下文章