数据库及分布式事务

1.数据库的存储引擎（底层软件组织），数据库管理系统DBMS使用它增删改查，不同的存储引擎有不同的风格（存储机制，索引技巧，锁定水平），常用的存储引擎，MyIASM(默认),InnoDB,Memory,Archive,Federate

2.MyIASM。它不支持数据库事务，行级锁，外键。特点：读取速度比InnoDB快，占用内存较少。Innodb寻址时先映射到块，再映射到行

InnoDB：支持事务，崩溃修复能力，多版本并发控制，事务安全。InnoDB的底层存储结构是B+树。

3.为什么InnoDB的存储结构采用B+树

数据库表中的数据都是存储在页中的，所以一个页中能存储多少行数据呢？

假设一行数据的大小是1k，那么一个页可以存放16行这样的数据。

如果数据库只按这样的方式存储，如何查找数据就成为一个问题，因为不知道要查找的数据存在哪个页中，也不可能把所有的页遍历一遍，那样太慢了。

不过，可以使用B+树的方式组织这些数据，如图所示：

 

 

先将数据记录按主键进行排序，分别存放在不同的页中（为了便于理解这里一个页中只存放3条记录，实际情况可以存放很多）

除了存放数据的页以外，还有存放键值+指针的页，如图中page number=3的页，该页存放键值和指向数据页的指针，这样的页由N个键值+指针组成。

当然它也是排好序的。这样的数据组织形式，我们称为索引组织表。

现在来看下，要查找一条数据，怎么查？

如：select * from user where id=5;

这里id是主键，通过这棵B+树来查找，首先找到根页，你怎么知道user表的根页在哪呢？

其实每张表的根页位置在表空间文件中是固定的，即page number=3的页。

找到根页后通过二分查找法，定位到id=5的数据应该在指针P5指向的页中，那么进一步去page number=5的页中查找，同样通过二分查询法即可找到id=5的记录：

总结一下：

InnoDB存储引擎的最小存储单元是页，页可以用于存放数据也可以用于存放键值+指针，在B+树中叶子节点存放数据，非叶子节点存放键值+指针。

索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中，进而在去数据页中查找到需要的数据；

4.InnoDB应用场景

• 经常有数据更新的表，适合处理有多重并发更新情景

• 支持事务支持灾难恢复

• 支持外键约束，只有InnoDB支持外键

• 支持自动增加列属性

5.TokuDB底层存储结构是Fractal Tree（分形树），TokuDB在线添加索引，不影响读写操作，有非常高的写入性能，主要适用于要求写入速度快，访问频率不高的数据或历史数据归档

6.Memory表使用内存空间创建，数据存放在内存中，因此读取速度飞快，通常使用hash索引来实现数据索引。缺点是服务器一旦关闭，数据丢失。

7.创建索引的原则--------创建索引是提高数据库查询速度的常用方法。

• 选择唯一性索引（hash）
• 为经常需要排序，分组和联合操作的字段建立索引
• 为经常需要作为查询条件的字段建立索引
• 限制索引数量（索引过多，表更新越慢）
• 尽量使用数据量少的索引（防止速度变慢）
• 尽量使用前缀来索引
• 删除不再使用或很少使用的索引
• 尽量选择区分度较高的列作为索引
• 索引列不参与运算
• 尽量扩展现有索引

8.数据库的三范式
第一范式：每一列都不可再分（列的原子性）

第二范式：在第一范式的基础上，每一个表都不可再分，每个表只描述一个事情（表的原子性）

第三范式：在第一范式，第二范式基础上，列不存在对非主键的传递依赖

9.数据库事务

• 原子性
• 一致性（事务执行完数据保持一致）
• 隔离性（事务之间彼此互不干扰，彼此隔离）
• 永久性（事务执行完毕，修改后的数据将被持久化到内存中）

10.存储过程优化常见思路

• 尽量使用sql语句代替一些小循环
• 中间结果存放于临时表中，并加上索引
• 少使用游标（cursor）
• 事务括的代码越少越好
• 使用try-catch处理异常
• 尽量不要将查询语句放在循环中

 

11. 数据库的并发控制一般采用三种方式实现，乐观锁，悲观锁，时间戳（多一个时间戳列，更新数据时时间戳加1，提交时比较时间戳，如果大1，就保存，否则不保存）

12. 数据库锁

行级锁：对某行数据加锁。

表级锁：指对当前操作的整张表加锁

页级锁：粒度在行级锁和表级锁之间

13.数据库分表

1. 垂直切分：分类。一个库存一种表
2. 水平切分：分割。同种表太多，分割到多个库中存储

14.两阶段提交协议（加上一个协调者）

指在数据库领域及计算机网络内，为了使分布式数据库中所有节点在提交时都保持一致性而设计的一种算法。

思路：参与者将失败反馈给协调者，由协调者决定所有参与者是提交操作还是终止操作

1. 准备阶段（Prepare）：协调者发送prepare信号
2. Commit（提交节点）：协调者发送commit或者rollback信号

缺点：

1. 同步阻塞问题：所有参与者都是阻塞执行的
2. 单点故障：如果协调者故障，所有人阻塞
3. 数据不一致：只有一部分参与者接受到了协调者第二阶段的commit信息，造成数据不一致（脑裂）
4. 协调者宕机事务状态丢失：协调者与参与者都宕机，通过协调者选取协议产生新的协调者之后，宕机参与者的状态将丢失，没有知道它接受到信号之后执行到哪了

15.三阶段提交协议

1. CanCommit阶段
2. PreCommit阶段：如果有参与者返回no，那么所有事务终止
3. DoCommit阶段

16.分布式事务

1. 传统事务（CAP）
2. 柔性事务---Alibaba（基本可用（Basically Available），柔性状态（Soft State），最终一致性（Eventual Consistency））

两阶段型

补偿型TCC（try，commit，cancel）：参与者服务器失败，那么发起者服务器和参与者服务器都恢复到原来的数据（依靠日志恢复）

异步确保型：指一系列同步的事务操作更改为基于消息队列异步执行的操作，提高数据操作性能

最大努力通知型（牺牲一致性）：指发起者服务器尽全力（最大次数）通知参与者服务器，超过最大次数后停止通知，这时会造成数据不一致，但是提高了性能高效。