MySQL事务、锁

事务描述：

在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。事务它还可以用来管理DDL、DML、DCL操作，比如 insert,update,delete 语句。一般来说，事务是必须满足4个条件（ACID）：

Atomicity（原子性）：

      构成事务的的所有操作必须是一个逻辑单元，要么全部执行，要么全部不执行

Consistency（稳定性、一致性）：

     数据库在事务执行前后状态都必须是稳定的、保持一致的。

Isolation（隔离性）：

     事务之间不会相互影响。

Durability（可靠性、持久性）：

    事务执行成功后必须全部写入磁盘。

常见的操作有一下三个：

BEGIN或START TRANSACTION；显式地开启一个事务；

关闭事务：

COMMIT；也可以使用COMMIT WORK，不过二者是等价的。COMMIT会提交事务，并使已对数据库进行的所有修改称为永久性的；

ROLLBACK；有可以使用ROLLBACK WORK，不过二者是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改；

在 MySQL 命令行的默认设置下，事务都是自动提交的，即执行 SQL 语句后就会马上执行 COMMIT 操作。因此要显式地开启一个事务务须使用命令 BEGIN 或 START TRANSACTION，或者执行命令 SET AUTOCOMMIT=0，用来禁止使用当前会话的自动提交。

事务并发：

在事务的并发操作中可能会出现一些问题：

脏读：一个事务读取到另一个事务未提交的数据。

不可重复读：一个事务因读取到另一个事务已提交的数据。导致对同一条记录读取两次以上的结果不一致。update操作

幻读：一个事务因读取到另一个事务已提交的数据。导致对同一张表读取两次以上的结果不一致。insert、delete操作

 事务隔离：

为了避免事务出现并发问题，在标准sql规划中定义了4个事务隔离级别，不同的隔离级别对事务处理不同。

由低到高：

①  Read uncommitted (读未提交)：最低级别，任何情况都无法保证。

②  Read committed (读已提交)：可避免脏读的发生。

③  Repeatable read (可重复读)：可避免脏读、不可重复读的发生。

④  Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。

大多数数据库的默认隔离级别是Read committed，比如Oracle、DB2等。

MySQL数据库的默认隔离级别是Repeatable read。

查看当前事务级别：

 select @@tx_isolation;

设置事务隔离级别：

set  [glogal | session]  transaction isolation level 隔离级别名称;

 set tx_isolation=’隔离级别名称;’

隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。

对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制。

MySQL锁：

MySQL数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别，总的来说，MySQL各存储引擎使用了三种类型（级别）的锁定机制：行级锁定，页级锁定和表级锁定。下面我们先分析一下MySQL这三种锁定的特点和各自的优劣所在。

行级锁定（row-level）：

行级锁定最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能。虽然能够在并发处理能力上面有较大的优势，但是行级锁定也因此带来了不少弊端。由于锁定资源的颗粒度很小，所以每次获取锁和释放锁需要做的事情也更多，带来的消耗自然也就更大了。此外，行级锁定也最容易发生死锁。

表级锁定（table-level）

和行级锁定相反，表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并大度大打折扣。

MySQL的表级锁定有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。

table_locks_immediate：产生表级锁定的次数；

table_locks_waited：出现表级锁定争用而发生等待的次数；

手动增加表及锁：

lock table 表名称 read(write),表名称2 read(write)，其他;

查看表锁的情况：

show open tables;

删除表锁：

unlock tables;

页级锁定（page-level）：

页级锁定是MySQL中比较独特的一种锁定级别，在其他数据库管理软件中也并不是太常见。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处理能力也同样是介于上面二者之间。另外，页级锁定和行级锁定一样，会发生死锁。

表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；

行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高；

页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

InnoDB引擎的锁机制

InnoDB行锁是通过给索引上的索引项加锁来实现的，因此InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！。

InnoDB的行级锁定同样分为两种类型，共享锁和排他锁，而在锁定机制的实现过程中为了让行级锁定和表级锁定共存，InnoDB也同样使用了意向锁（表级锁定）的概念，也就有了意向共享锁和意向排他锁这两种。

 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（等待总时长）这三项。

尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。