Log[数据库_事务与索引]_20.07.04

事务

事务可以由一条或多条语句组成。在事务的操作中，要么将所有操作都做完，要么就都不做。

1.事务的四大特性

原子性：整个事务应该被视为原子操作，即要么把操作都做完，要么都不做。事务中任何一个SQL语句执行失败，已经执行成果的SQL语句也必须撤销，数据库状态回退到执行事务前。依靠redo log实现（详见2.1）

一致性：一致性是指事务将数据库从一种正确状态转变为下一种正确的状态，在状态的转变中，不能破坏我们设置的约束。依靠undo log实现（详见2.2）

隔离性：每个读写事务的对象对其他事务的操作对象能相互分离，即该事务提交前对其他事务都不可见，其他事务无法对其进行操作，主要依靠锁来实现。

持久性：事务一旦提交，结果就是永久性的。即使数据库因为崩溃而需要恢复，也能保证恢复后提交的数据都不会消失。依靠redo log来实现。（详见2.1）

2.事务的实现

2.1 redo（保证原子性和持久性）

基本概念：redo log是物理日志，记录页的物理修改操作。

由两部分组成：重做日志缓冲（易失）+重做日志文件（持久）。

当事务提交时，必须先将该事务的所有日志写到重做日志文件进行持久化，待事务提交时才算完成。为了确保每次日志都写入重做日志文件，在每次将重做日志缓冲写入重做日志文件后，都要调用一次fsync操作（确保文件所有已修改的内容都已经同步到了磁盘上，是一个同步操作，比异步的更安全）

2.2 undo（保证一致性）

如果用户执行事务或语句失败，又或者调用了ROLLBACK语句请求回滚，这时候就可以利用undo日志将数据回滚到修改前的样子。要注意通过undolog回滚并不是将页物理地还原成原来的样子，而是在逻辑上取消某些操作而已。因为一个表可能有多个事务对不同地记录在进行操作，不能影响其他事务对表的改变。

3.事务的隔离级别

读未提交：A事务读记录之前，B事务对记录进行了修改但是并未提交，使A事务读到了未提交的数据，由此就产生了问题：脏读。

读提交：规定事务提交后的数据才对其他事务可见.解决了脏读的问题，还存在的问题是幻读：即事务A的两次读操作中间，事务B对记录做了更改并提交，导致A的两次读数据不一样，但很多时候业务要求在一个事务内读到的数据必须相同，由此就产生了问题：不可重复读。

可重复读:j解决了上述不可重复读的问题，但是还有问题：幻读——即事务A的两次读操作中间，事务B对记录做了添加/删除并提交，导致A的两次读操作会出现增行/少行现象。

串行化：事务串行化执行，但效率奇差。

索引与算法

1.先导

1.1 索引概述（基于InnoDB引擎）

​ 在InnoDB引擎下，聚集索引与数据同在一颗B+树上。B+树索引并不能找到一个给定键值的具体行，B+树索引能找到的只是被查找数据行所在的页，然后数据库通过把页读入到内存，再在内存中进行查找，最后得到要查找的数据。

1.2 B+树

B+树是一颗平衡查找树，所有的记录节点按照键值的大小顺序放在同一层的叶子节点上，由各叶子节点指针进行连接。

1.2.1 B+树的插入

​ 插入有三种情况，分别对应不同的插入方法：

① 叶子节点与索引结点都未满：直接将记录插入叶子节点

② 叶子节点满而索引节点未满：将叶子节点拆分，然后将中间的节点提升到索引中，然后小于中间节点的记录放左边，大于或等于中间节点的记录放右边

③ 子节点与索引节点都满：以相同的规则拆分叶子节点和索引节点。

可以看到为了保证有序做了大量拆分页的工作，拆分页意味着磁盘操作，而磁盘操作也就意味着慢。所以要尽量减少磁盘操作，为此B+树引入了旋转操作。

旋转发生的条件是：应该插入的叶子节点已经满，但是左右兄弟没有满。此时先检查左节点满不满足旋转条件，满足的话就做操作。

由此，B+树的优势又可以收集一条：方便插入旋转，提升效率。（上一条是查找范围数据方便）

1.2.2 B+树的删除

B+树用填充因子（默认50%）来控制树的删除。同样有三种情况：

① 叶节点和索引节点都大于填充因子：直接删除，若该节点还存在于索引节点中，用右节点代替

② 叶节点小于填充因子，索引节点大于填充因子：合并叶子节点和它的兄弟节点，同时更新索引节点

③ 叶子节点和索引节点都小于填充因子：两个都做合并操作，别忘了更新索引节点

2. B+树的索引

Tips：B+树索引有一个特性是高扇出性，因此在数据库中树的高度一般在2~4层，也就是说查找某一行记录时最多只需要2到4次IO。

2.1 聚集索引

​ 聚集索引，就是按照每张表的主键构造一棵B+树，同时叶子节点中存放的即为整张表的行记录数据，所以聚集索引中的叶子节点也称为数据页。每个数据页都通过双向链表进行链接。

在索引页上，存储的是键值以及指向数据页的偏移量；而数据页上存放的时完整的每行的记录。

如图：

聚集索引的好处：对于主键的排序查找和范围查找速度非常快。

2.2 辅助索引

对于辅助索引（非聚集索引），叶子节点并不包括行记录的全部数据。叶子节点包含的有两个：键值和书签，该书签用来告诉InnoDB存储引擎哪里可以找到与索引相对应的行数据。说白了就是相应行数据的聚集索引键。

当通过辅助索引来寻找数据时，InnoDB存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键，然后再通过主键索引来找到一个完整的行记录。

如图：

2.3 索引的分裂和管理

​ 索引的分裂不能总是从中间分开，这样可能会导致前页不会插入数据而产生前页空间的浪费。

​ 所以InnoDB选取分裂点的规则是：若插入随机，则取中间；若同一方向进行插入的记录数量为5，而且目前已经定位到的记录之后还有至少三条记录，那就将分裂点定为定位点后三条的那个记录，目的是尽可能让前页有数据可插入。

索引的各个属性：

数据库为表添加或删除主键索引的方法是创建新的临时表——>原表数据导入到临时表——>删除原表——>临时表重命名为原来的表名

2.4 联合索引

​ 是指对表上多个列进行索引。联合索引本质上也是一颗B+树，只不过键值数量大于等于2。

当查询的字段属于一个单个索引也属于联合索引时，索引使用的是单个索引，因为单个索引键值小，每个节点（也就是每个页）中存放的数据也更多，找起来更方便。

Tips：预读——一次IO时，不光把当前磁盘地址的数据读出来，把其相邻一段长度的数据也读到内存缓冲区。预读的长度一般为页的整倍数。

3. 全文检索

全文索引是将存储于数据库的整本书或整篇文章中的任意内容信息查找出来的技术。可以根据需要获取全文中有关章、字、段、句、词等信息。

3.1 倒排索引

倒排索引也是一种索引结构，它在辅助表中存储了单词与单词自身在一个或多个文档中所在位置之间的映射。通常用关联数组实现，拥有两种表现形式：

① {单词，单词所在文档的ID}

Number	Text	Documents
1	code	1，4
2	days	3，6

② {单词，{单词所在文档ID，在具体文档的位置}}

Number	Text	Doucments
1	code	（1：6），（4：8）
2	days	（3：2），（6：2）

3.2 InnoDB全文检索

采用上述第二种方式，将（文章id，位置）视为一个ilist。因此在全文索引表中有两个列：一个是word字段，一个是ilist，并且word字段上有索引。

需要说明的是每张表只有一个全文检索的索引。