2. 事务

1. delete 语句的和查询的加锁方式相同
2. limit 语句，遍历到满足条件的 n 条数据后，之后不再加 next-key lock

死锁：不同线程可以给同一个间隙加锁。

意思时只有我这个线程可以操控这个间隙，其他线程不能使用，加锁时不会检测是否冲突的，但是如果两个都给同一个间隙上锁，之后两个线程都没办法在这个间隙上更新数据了，都会陷入等待另一个线程的间隙锁释放，也就是

死锁。

如果使用读提交隔离级别，那么只加行锁，不加间隙锁，语句执行过程中加上的行锁，在语句执行完成后，就要把 “不满足条件的行”上的行锁直接释放了，不需要等到事务提交才释放。

2. 事务

2-1：for update的使用场景

一般这些操作都是很长一串并且是开启事务的。

如果库存刚开始读的时候是1，而立马另一个进程进行了update将库存更新为0了，而事务还没有结束，会将错的数据一直执行下去，就会有问题。

需要 for upate 进行数据加锁防止高并发时候数据出错，即使事务保持当前读状态。

SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset;

# 如果只给定一个参数，表示记录数。

mysql> SELECT * FROM orange LIMIT 5;# 检索前5条记录(1-5)

相当于

mysql> SELECT * from orange LIMIT 0,5;

两个参数，第一个参数表示offset, 第二个参数为记录数。

mysql> SELECT * FROM orange LIMIT 10,15; // 检索记录11-25

如果你想要清除一些MySQL使用内部缓存，你应该使用FLUSH命令

2-2：事务隔离

innodb 支持 RC 和 RR 隔离级别实现是用的一致性视图(consistent read view)

事务在启动时会拍一个快照,这个快照是基于整个库的。

基于整个库的意思就是说一个事务内,整个库的修改对于该事务都是不可见的(对于快照读的情况)

如果在事务内 select t 表,另外的事务执行了DDL t表,根据发生时间,只有两种情况

1. 报错

（2）事务在启动时,找到已提交的最大事务ID记为up_limit_id。

（3）事务在更新一条语句时

比如 id=1 改为了 id=2.会把 id=1 和该行之前的 row trx_id 写到 undo log 里, 并且在数据页上把 id 的值改为 2,并且把修改这条语句的transaction id 记在该行行头

（4）再定一个规矩

一个事务要查看一条数据时,必须先用该事务的 up_limit_id 与该行的transaction id 做比对

如果 up_limit_id >= transaction id,那么可以看如果 up_limit_id < transaction id,则只能去 undo log 里去取。

去 undo log 查找数据的时候,也需要做比对,必须 up_limit_id > transaction id，才返回数据

2-3：什么是当前读

由于当前读都是先读后写,只能读当前的值,所以为当前读会更新事务内的 up_limit_id 为该事务的 transaction

你提到了隐藏列有一个DB_ROW_ID，是干嘛的？那假设有10个update，到第九个回滚了，DB_ROLL_PTR如何做的，那提交了是否更新DB_ROLL_PTR？

为什么 rr 能实现可重复读而 rc 不能,分两种情况

（1）快照读的情况下：

rr不能更新事务内的 up_limit_id ,而 rc 每次会把 up_limit_id 更新为快照读之前最新已提交事务的 transaction id, 则 rc 不能可重复读

（2）当前读的情况下：

rr 是利用 record lock+gap lock来实现的,而 rc 没有 gap,所以 rc 不能可重复读

2-4：选择普通索引还是唯一索引？

1、对于查询过程来说：

（1）普通索引

查到满足条件的第一个记录后，继续查找下一个记录，知道第一个不满足条件的记录

（2）唯一索引

由于索引唯一性，查到第一个满足条件的记录后，停止检索

但是，两者的性能差距微乎其微。因为InnoDB根据数据页来读写的。

2、对于更新过程来说：

概念：change buffer

当需要更新一个数据页：

purge：将 change buffer 中的操作应用到原数据页上，得到最新结果的过程，成为 purge

访问这个数据页会触发 purge，系统有后台线程定期 purge，在数据库正常关闭的过程中，也会执行 purge

唯一索引的更新不能使用 change buffer

change buffer 用的是 buffer pool 里的内存，change buffer 的大小，可以通过参数 innodb_change_buffer_max_size 来动态设置。这个参数设置为50的时候，表示 change buffer 的大小最多只能

占用 buffer pool 的50%。

将数据从磁盘读入内存涉及随机IO的访问，是数据库里面成本最高的操作之一。

change buffer 因为减少了随机磁盘访问，所以对更新性能的提升很明显。

change buffer使用场景：

在一个数据页做purge之前，change buffer记录的变更越多，收益就越大。

对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时change buffer的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。

反过来，假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在change buffer,但之后由于马上要访问这个数据页，会立即触发purge过程。

这样随机访问IO的次数不会减少，反而增加了change buffer的维护代价。所以，对于这种业务模式来说，change buffer反而起到了副作用。

索引的选择和实践：

尽可能使用普通索引。

redo log主要节省的是随机写磁盘的IO消耗(转成顺序写)，而change buffer主要节省的则是随机读磁盘的IO消耗。

2-5：char 和 varchar 的区别？

char 是固定长度类型，比如：定义 char(10)，当你输入”abc”三个字符的时候，它们占的空间还是 10 个字节，其他 7 个是空字节。varchar 长度可变

存储情况不同

以 compact 行格式为例：

一条完整的记录由两部分组成

1. 变长字段的真正数据内容
2. 该变长字段所占用的字节数

该变长字段所占用的字节数被放在变长字段列表中，并且按照列的顺序逆序存放。

而 char 类型的数据则只需要存储其真正的数据内容。

对于类型为 char(M) 的列