标签：starting 手工 mod personal https red pre 语句 serial
在 InnoDB 中，MVCC 和锁是协同使用的，这两种方案并不是互斥的。
按照惯例，还是把相关概念解释一下
什么是事务？
维基百科：事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成；
原子性：对数据库的一系列的操作，要么都是成功，要么都是失败，不可能出现部分成功或者部分失败的情况；
原子性，在 InnoDB 里面是通过 undo log 来实现的，它记录了数据修改之前的值（逻辑日志），一旦发生异常，就可以用 undo log 来实现回滚操作。
一致性：是数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。
隔离性：在数据库里面会有很多的 事务同时去操作我们的同一张表或者同一行数据，必然会产生一些并发或者干扰的操作， 那么我们对隔离性的定义，就是这些很多个的事务，对表或者行的并发操作，应该是透明的，互相不干扰的。通过这种方式，我们最终也是保证业务数据的一致性。
持久性：我们对数据库的任意的操作，增删改，只要事务提交成功，那么结果就是永久性的，不可能因为我们系统宕机或者重启了数据库的服务器，它又恢复到原来的状态了；
持久性是通过 redo log 和 double write 双写缓冲来实现的。
MySQL中，InnoDB和NDB支持事务
spring的事务依赖于数据库实现，通过切面或注解实现不同的事务：
<tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes>
<tx:method name="save*" rollback-for="Throwable" />
<tx:method name="add*" rollback-for="Throwable" />
<tx:method name="send*" rollback-for="Throwable" />
<tx:method name="insert*" rollback-for="Throwable" />
</tx:attributes> </tx:advice>
MySQL 的事务启动方式有以下几种：
1、显式启动事务语句， begin 或 start transaction。配套的提交语句是 commit，回滚语句是 rollback。
2、set autocommit=0，这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个 select 语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行 commit 或 rollback 语句，或者断开连接。
-- 查看数据库版本
select version();
-- 查看数据库引擎
show variables like ‘%engine%‘;
-- 查看事务的隔离级别
show global variables like "tx_isolation";
-- 查看数据的事务提交方式
show variables like ‘autocommit‘;
-- 设置自动提交->回话级别
set global autocommit=0;
-- 修改配置文件
init_connect=‘SET autocommit=off‘;
读未提交：一个事务还没提交时，它做的变更就能被别的事务看到。
读提交：一个事务提交之后，它做的变更才会被其他事务看到。
可重复读:一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
串行化:顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。
脏读：A事务读取B事务尚未提交的数据并在此基础上操作，而B事务执行回滚，那么A读取到的数据就是脏数据
不可重复读：事务A重新读取前面读取过的数据，发现该数据已经被另一个已提交的事务B修改过了。
幻读：事务A重新执行一个查询，返回一系列符合查询条件的行，发现其中插入了被事务B提交的行。
SQL92标准描述了隔离级别与数据读一致性问题
? P1 P2 P3 就是 代表事务并发的 3 个问题;
? 图片中的蓝色文字，在了解了InnoDB的锁之后，就会明白
1、LBCC
? 我既然要保证前后两次读取数据一致，那么我读取数据的时候，锁定我要 操作的数据，不允许其他的事务修改就行了。这种方案我们叫做基于锁的并发控制 Lock Based Concurrency Control（LBCC）。 如果仅仅是基于锁来实现事务隔离，一个事务读取的时候不允许其他时候修改，那 就意味着不支持并发的读写操作，而我们的大多数应用都是读多写少的，这样会极大地 影响操作数据的效率。
2、MVCC
? 如果要让一个事务前后两次读取的数据保持一致， 那么我们可以在修改数据的时候给它建立一个备份或者叫快照，后面再来读取这个快照 就行了。这种方案我们叫做多版本的并发控制 Multi Version Concurrency Control （MVCC）。
? MVCC 的核心思想是： 我可以查到在我这个事务开始之前已经存在的数据，即使它
在后面被修改或者删除了。在我这个事务之后新增的数据，我是查不到的。
分别对应的是：
- 共享锁和独占锁
- 意向锁
- 记录锁
- 间隙锁
- 临键锁
- 插入意向锁
- AUTO_INCREMENT列的表中插入数据时需要获取的一种特殊的表级锁
- 谓词锁
行锁、表锁：表锁，顾名思义，是锁住一张表；行锁就是锁住表里面的一行数据。
| 锁分类 | 行锁 | 表锁 |
|---|---|---|
| 锁定粒度 | 小于表锁 | |
| 冲突概率 | 表锁的冲突概率更大，所以并发性能更低 |
共享锁：也叫读锁，一个事务获取了一行数据的读锁之后，其他的事务可以再次获取查询数据，需要注意的是：不要在加上了读锁以后去写数据，不然的话可能会出现死锁的情况。
可以用 select …… lock in share mode;的方式手工加上一把读锁。
释放锁有两种方式，只要事务结束，锁就会自动释放事务，包括提交事务和结束事务。
第二个行级别的锁叫做 Exclusive Locks（排它锁），它是用来操作数据的，所以又叫做写锁。只要一个事务获取了一行数据的排它锁，其他的事务就不能再获取这一行数据的共享锁和排它锁。
1、排它锁的加锁方式有两种，第一种是自动加排他锁。我们在操作数据的时候，包括增删改，都会默认加上一个排它锁。
2、还有一种是手工加锁，我们用一个 FOR UPDATE 给一行数据加上一个排它锁，这个无论是在我们的代码里面还是操作数据的工具里面，都比较常用。
当我们给一行数据加上共享锁之前，数据库会自动在这张表上面加一个意向共享锁。
当我们给一行数据加上排他锁之前，数据库会自动在这张表上面加一个意向排他锁。
? 1、如果一张表上面至少有一个意向共享锁，说明有其他的事务给其中的某些数据行加上了共享锁。
? 2、如果一张表上面至少有一个意向排他锁，说明有其他的事务给其中的某些数据行加上了排他锁。
? 当我们需要使用表锁的时候（改变表结构），需要去判断是否数据加了行锁，如果是最后一行，数据量大的情况下，效率就特别低，而意向锁解决了这个问题；
到这里我们要思考两个问题:
1.锁的作用是什么？
它跟 Java 里面的锁是一样的， 是为了解决资源竞争的问题，Java 里面的资源是对象，数据库的资源就是数据表或者数 据行。所以锁是用来解决事务对数据的并发访问的问题的。
2.那么，锁到底锁住了什么呢？
当一个事务锁住了一行数据的时候，其他的事务不能操作这一行数据，那它到底是锁住了这一行数据，还是锁住了这一个字段，还是锁住了别的什么东西呢？
锁锁住的是主键索引：是不是有很多问题？
1、为什么表里面没有索引的时候，锁住一行数据会导致锁表？ 或者说，如果锁住的是索引，一张表没有索引怎么办？ 所以，一张表有没有可能没有索引？
1）如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择主键作为聚集索引。
2）如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引作为主键索引。
3）如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐藏的聚集索引，它会随着行记录的写入而主键递增。
所以，为什么锁表，是因为查询没有使用索引，会进行全表扫描，然后把每一个隐藏的聚集索引都锁住了。
2、为什么通过唯一索引给数据行加锁，主键索引也会被锁住？
我们通过辅助索引锁定一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引，然锁住主键索引
数据库里面存在的主键值，我们把它叫做 Record，记录，那么这里我们就有 4个 Record。
根据主键，这些存在的 Record 隔开的数据不存在的区间，我们把它叫做 Gap，间隙，它是一个左开右开的区间。
间隙（Gap）连同它左边的记录（Record），我们把它叫做临键的区间，它是一个左开右闭的区间。
若果主键为非整数类型，通过用ASCII码来排序。
第一种情况，当我们对于唯一性的索引（包括唯一索引和主键索引）使用等值查询，精准匹配到一条记录的时候，这个时候使用的就是记录锁。
? where id = 1 4 7 10
第二种情况，当我们查询的记录不存在，没有命中任何一个 record，无论是用等值
查询还是范围查询的时候，它使用的都是间隙锁。where id >4 and id <7，where id = 6。
Gap Lock 只在 RR 中存在。如果要关闭间隙锁，就是把事务隔离级别设置成 RC，并且把 innodb_locks_unsafe_for_binlog 设置为 ON。这种情况下除了外键约束和唯一性检查会加间隙锁，其他情况都不会用间隙锁。
第三种情况，当我们使用了范围查询，不仅仅命中了 Record 记录，还包含了 Gap间隙，在这种情况下我们使用的就是临键锁，它是 MySQL 里面默认的行锁算法，相当于
记录锁加上间隙锁。
唯一性索引，等值查询匹配到一条记录的时候，退化成记录锁。
没有匹配到任何记录的时候，退化成间隙锁。
比如我们使用>5 <9， 它包含了记录不存在的区间，也包含了一个 Record 7。
为什么要锁住下一个左开右闭的区间？——就是为了解决幻读的问题
再次回顾一下这张表
Read Uncommited：RU 隔离级别：不加锁
Serializable：Serializable 所有的 select 语句都会被隐式的转化为 select ... in share mode，会和update、delete 互斥。
Repeatable Read：
Read Commited：
RC 隔离级别下，普通的 select 都是快照读，使用 MVCC 实现。
加锁的 select 都使用记录锁，因为没有 Gap Lock
除了两种特殊情况——外键约束检查(foreign-key constraint checking)以及重复键检查(duplicate-key checking)时会使用间隙锁封锁区间；所以 RC 会出现幻读的问题。
RU 和 Serializable 肯定不能用。为什么有些公司要用 RC，或者说网上有些文章推荐有 RC？
RC 和 RR 主要有几个区别：
? 1、 RR 的间隙锁会导致锁定范围的扩大。
? 2、 条件列未使用到索引，RR 锁表，RC 锁行。
? 3、 RC 的“半一致性”（semi-consistent）读可以增加 update 操作的并发性。
? 在 RC 中，一个 update 语句，如果读到一行已经加锁的记录，此时 InnoDB 返回记录最近提交的版本，由 MySQL 上层判断此版本是否满足 update 的 where 条件。若满足(需要更新)，则 MySQL 会重新发起一次读操作，此时会读取行的最新版本(并加锁)。
? 实际上，如果能够正确地使用锁（避免不使用索引去枷锁），只锁定需要的数据，用默认的 RR 级别就可以了。
? 在我们使用锁的时候，有一个问题是需要注意和避免的，我们知道，排它锁有互斥的特性。一个事务或者说一个线程持有锁的时候，会阻止其他的线程获取锁，这个时候会造成阻塞等待，如果循环等待，会有可能造成死锁。
锁什么时候释放：事务结束（commit，rollback）；客户端连接断开。
如果一个事务一直未释放锁，其他事务会被阻塞多久？会不会永远等待下去？如果
是，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占
用大量计算机资源，造成严重性能问题，甚至拖跨数据库。
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction
-- 查看系统锁释放的时间
show VARIABLES like ‘innodb_lock_wait_timeout‘;
为什么可以直接检测到呢？
是因为死锁的发生需要满足一定的条件，所以在发生死 锁时，InnoDB 一般都能通过算法（wait-for graph）自动检测到。
那么死锁需要满足什么条件？
（1）因为锁本身是互斥的:同一时刻只能有一个事务持有这把锁，
（2）其他的事务需要在这个事务释放锁之后才能获取锁，而不可以强行剥夺，
（3）当多个事务形成等 待环路的时候，即发生死锁
show status like ‘innodb_row_lock_%‘;
Innodb_row_lock_current_waits：当前正在等待锁定的数量；
Innodb_row_lock_time ：从系统启动到现在锁定的总时间长度，单位 ms；
Innodb_row_lock_time_avg ：每次等待所花平均时间；
Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花的时间；
Innodb_row_lock_waits ：从系统启动到现在总共等待的次数。
-- 当前运行的所有事务 ，还有具体的语句
select * from information_schema.INNODB_TRX;
-- 当前出现的锁
select * from information_schema.INNODB_LOCKS;
-- 锁等待的对应关系
select * from information_schema.INNODB_LOCK_WAITS;
? 如果一个事务长时间持有锁不释放，可以 kill 事务对应的线程 ID，也就是 INNODB_TRX 表中的 trx_mysql_thread_id，例如执行 kill 4，kill 7，kill 8。 当然，死锁的问题不能每次都靠 kill 线程来解决，这是治标不治本的行为。我们应该尽量在应用端，也就是在编码的过程中避免。
1、 在程序中，操作多张表时，尽量以相同的顺序来访问（避免形成等待环路）；
2、 批量操作单张表数据的时候，先对数据进行排序（避免形成等待环路）；
3、 申请足够级别的锁，如果要操作数据，就申请排它锁；
4、 尽量使用索引访问数据，避免没有 where 条件的操作，避免锁表；
5、 如果可以，大事务化成小事务；
6、 使用等值查询而不是范围查询查询数据，命中记录，避免间隙锁对并发的影响。
原文 https://www.cnblogs.com/liweiweicode/p/12674306.html
标签：starting 手工 mod personal https red pre 语句 serial
原文地址：https://www.cnblogs.com/php-linux/p/13258742.html
