标签：技术 back current 页面 串行 不能 stat ODB its
接下来我会带大家一起来熟悉mysql中的事务处理机制
l 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。
l 事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。
l 事务用来管理DDL、DML、DCL操作，比如 insert,update,delete 语句
一般来说，事务必须满足四个条件
1. Atomicity（原子性）
原子性：构成事务的的所有操作必须是一个逻辑单元，要么全部执行，要么全部不执行。
2. Consistency（稳定性、一致性）
稳定性（一致性）：数据库在事务执行前后状态都必须是稳定的。
3. Isolation（隔离性）
隔离性：事务之间不会相互影响。
4. Durability（可靠性、持久性）
可靠性（持久性）：事务执行成功后必须全部写入磁盘 。
常见的操作有三步
1. BEGIN或START TRANSACTION；显式地开启一个事务；
2. COMMIT；也可以使用COMMIT WORK，不过二者是等价的。COMMIT会提交事务，并使已对数据库进行的所有修改称为永久性的；
3. ROLLBACK；有可以使用ROLLBACK WORK，不过二者是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改；
大概的说：
在 MySQL 命令行的默认设置下，事务都是自动提交的，即执行 SQL 语句后就会马上执行 COMMIT 操作。因此要显式地开启一个事务务须使用命令 BEGIN 或 START TRANSACTION，或者执行命令 SET AUTOCOMMIT=0，用来禁止使用当前会话的自动提交。
创建表
插入数据
提交测试
回滚测试
我们在进行事务并发问题时，可能会发生以下问题
1.脏读：个事务读取到另一个事务未提交的数据。
2.不可重复读：一个事务因读取到另一个事务已提交的数据。导致对同一条记录读取两次以上的结果不一致。update操作
3.幻读：一个事务因读取到另一个事务已提交的数据。导致对同一张表读取两次以上的结果不一致。insert、delete操作
为了避免上面出现的几种情况，在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同
1. 四种隔离级别：
现在来看看MySQL数据库为我们提供的四种隔离级别（由低到高）：
① Read uncommitted (读未提交)：最低级别，任何情况都无法保证。
② Read committed (读已提交)：可避免脏读的发生。
③ Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
④ Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
2. 默认隔离级别
大多数数据库的默认隔离级别是Read committed，比如Oracle、DB2等。
MySQL数据库的默认隔离级别是Repeatable read。
3. 如何查看和设置隔离级别：
在MySQL数据库中查看当前事务的隔离级别：
select @@tx_isolation;
在MySQL数据库中设置事务的隔离 级别：
set [glogal | session] transaction isolation level 隔离级别名称;
set tx_isolation=’隔离级别名称;’
4.注意事项：
隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。
对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场 合，可以由应用程序采用悲观锁或乐观锁来控制。
* 数据库锁定机制简单来说就是数据库为了保证数据的一致性而使各种共享资源在被并发访问访问变得有序所设计的一种规则。
* 对于任何一种数据库来说都需要有相应的锁定机制，所以MySQL自然也不能例外。
* MySQL数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化 设计，所以各存储引擎的锁定机制也有较大区别。
* 总的来说，MySQL各存储引擎使用了三种类型（级别）的锁定机制：行级锁定，页级锁定和表级锁定。下面我们先分析一下MySQL这三种锁定的特点和各自的优劣所在。
1.行级锁定（row-level）
行级锁定最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处 理能力而提高一些需要高并发应用系统的整体性能。
虽然能够在并发处理能力上面有较大的优势，但是行级锁定也因此带来了不少弊端。由于锁定资源的颗粒度很小，所以每次获取锁和释放锁需要做的事情也更多，带来的消耗自然也就更大了。此外，行级锁定 也容易发生死锁。
2. 表级锁定（table-level）
和行级锁定相反，表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将 整个表锁定，所以可以很好的避免困扰我们的死锁问题。
当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并大度大打折扣。
3. 页级锁定（page-level）
页级锁定是MySQL中比较独特的一种锁定级别，在其他数据库管理软件中也并不是太常见。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处 理 能力也同样是介于上面二者之间。另外，页级锁定和行级锁定一样，会发生死锁。
总的来说，MySQL这3种锁的特性可大致归纳如下：
* 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；
* 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高；
* 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
MySQL的表级锁定有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。
MySQL 实现的表级锁定的争用状态变量：show status like ‘table%‘;
* table_locks_immediate：产生表级锁定的次数；
* table_locks_waited：出现表级锁定争用而发生等待的次数；
手动增加表锁
lock table 表名称 read(write),表名称2 read(write)，其他;
查看表锁情况
show open tables;
删除表锁
unlock tables;
读锁演示
写锁演示
共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
排他锁（X)：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。
意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。
说明：
1）共享锁和排他锁都是行锁，意向锁都是表锁，应用中我们只会使用到共享锁和排他锁，意向锁是mysql内部使用的，不需要用户干预。
2）对于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。
3）InnoDB行锁是通过给索引上的索引项加锁来实现的，因此InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！。
InnoDB的行级锁定同样分为两种类型，共享锁和排他锁，而在锁定机制的实现过程中为了让行级锁定和表级锁定共存，InnoDB也同样使用了意向锁（表级锁定）的概念，也就有了意向共享锁和意向排他锁这两种。
Innodb的锁定是通过在指向数据记录的第一个索引键之前和最后一个索引键之后的空域空间上标记锁定信息而实现的。Innodb的这种锁定实现方式被称为“NEXT-KEYlocking”（间隙锁），因为Query执行过程中通 过过范围查找的华，他会锁定整个范围内所有的索引键值，即使这个键值并不存在。
Innodb所使用的行级锁定状态查看：show status like ‘innodb_row_lock%‘;
* Innodb_row_lock_current_waits：当前正在等待锁定的数量；
* Innodb_row_lock_time：从系统启动到现在锁定总时间长度；
* Innodb_row_lock_time_avg：每次等待所花平均时间；
* Innodb_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；
* Innodb_row_lock_waits：系统启动后到现在总共等待的次数；
对于这5个状态变量，比较重要的主要是：
Innodb_row_lock_time_avg（等待平均时长）
Innodb_row_lock_waits（等待总次数）
Innodb_row_lock_time（等待总时长）这三项。
尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。
mysql> create table test_innodb_lock (a int(11),b varchar(16)) engine=innodb;
Query OK, 0 rows affected (0.02 sec)
mysql> create index test_innodb_a_idx on test_innodb_lock(a);
Query OK, 0 rows affected (0.05 sec)
Rcords: 0 Duplicates: 0 Warnings: 0
mysql> create index test_innodb_lock_b_idx on test_innodb_lock(b);
Query OK, 11 rows affected (0.01 sec)
Records: 11 Duplicates: 0 Warnings: 0
|
|
Session a |
Session b |
|
|
行锁定基本演示 |
|
|
1 |
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) |
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) |
|
|
mysql> update test_innodb_lock set b = ‘b1‘ where a = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 更新，但是不提交 |
|
|
2 |
|
mysql> update test_innodb_lock set b = ‘b1‘ where a = 1; 被阻塞，等待 |
|
3 |
mysql> commit; Query OK, 0 rows affected (0.05 sec) 提交 |
|
|
4 |
|
mysql> update test_innodb_lock set b = ‘b1‘ where a = 1; Query OK, 0 rows affected (36.14 sec) Rows matched: 1 Changed: 0 Warnings: 0 解除阻塞，更新正常进行 |
|
|
无索引升级为表锁演示 |
|
|
5 |
mysql> update test_innodb_lock set b = ‘2‘ where b = 2000; Query OK, 1 row affected (0.02 sec) Rows matched: 1 Changed: 1 Warnings: 0 |
mysql> update test_innodb_lock set b = ‘3‘ where b = 3000; 被阻塞，等待 |
|
6 |
|
|
|
7 |
mysql> commit; Query OK, 0 rows affected (0.10 sec) |
|
|
8 |
|
mysql> update test_innodb_lock set b = ‘3‘ where b = 3000; Query OK, 1 row affected (1 min 3.41 sec) Rows matched: 1 Changed: 1 Warnings: 0 阻塞解除，完成更新 |
|
|
间隙锁带来的插入问题演示 |
|
|
9 |
mysql> select * from test_innodb_lock; | a | b | | 1 | b2 | | 3 | 3 | | 4 | 4000 | | 5 | 5000 | | 6 | 6000 | | 7 | 7000 | | 8 | 8000 | | 9 | 9000 | | 1 | b1 | 9 rows in set (0.00 sec) mysql> update test_innodb_lock set b = a * 100 where a < 4 and a > 1; Query OK, 1 row affected (0.02 sec) Rows matched: 1 Changed: 1 Warnings: 0 |
|
|
10 |
|
mysql> insert into test_innodb_lock values(2,‘200‘); 被阻塞，等待 |
|
11 |
mysql> commit; Query OK, 0 rows affected (0.02 sec) |
|
|
12 |
|
mysql> insert into test_innodb_lock values(2,‘200‘); Query OK, 1 row affected (38.68 sec) 阻塞解除，完成插入 |
|
|
使用共同索引不同数据的阻塞示例 |
|
|
13 |
mysql> update test_innodb_lock set b = ‘bbbbb‘ where a = 1 and b = ‘b2‘; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 |
|
|
14 |
|
mysql> update test_innodb_lock set b = ‘bbbbb‘ where a = 1 and b = ‘b1‘; 被阻塞 |
|
15 |
mysql> commit; Query OK, 0 rows affected (0.02 sec) |
|
|
16 |
|
mysql> update test_innodb_lock set b = ‘bbbbb‘ where a = 1 and b = ‘b1‘; Query OK, 1 row affected (42.89 sec) Rows matched: 1 Changed: 1 Warnings: 0 session 提交事务，阻塞去除，更新完成 |
|
|
死锁示例 |
|
|
17 |
mysql> update t1 set id = 110 where id = 11; Query OK, 0 rows affected (0.00 sec) Rows matched: 0 Changed: 0 Warnings: 0 |
|
|
18 |
|
mysql> update t2 set id = 210 where id = 21; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 |
|
19 |
mysql>update t2 set id=2100 where id=21; 等待sessionb释放资源，被阻塞 |
|
|
20 |
|
mysql>update t1 set id=1100 where id=11; Query OK,0 rows affected (0.39sec) Rows matched: 0 Changed: 0 Warnings:0 等待sessiona释放资源，被阻塞 |
|
|
两个 session 互相等等待对方的资源释放之后才能释放自己的资源,造成了死锁 |
|
标签：技术 back current 页面 串行 不能 stat ODB its
原文地址：https://www.cnblogs.com/luoyong4516/p/12127993.html
