关系型数据库了解。在web开发中，通常使用的是MySQL。所以以MySQL为主体学习。
学习参照 极客时间 MySQL实战45讲 从某种层面来讲，MySQL系列也是实战阅读笔记。

对于MySQL，包括其他直接使用的组件来讲，我们作为使用者为什么要对其实现原理要有叫全面的认知。
第一步、一是根据类比，了解其核心作用以及定位，为组件选型提供背景知识。
第二步、当选择了某个特定的组件，怎么使用其提供的API，配置其提供的配置，不了解其整体实现机制，就没办法
有目的地调整。只能根据网上的只言片语去尝试，最后还不一定有效果。
第三步、当组件表现出了非预期行为时，要能够直捣黄龙，了解背后的原因，判断是使用姿势不对还是内部缺陷。
以此才能判断是通过调整使用方式还是换用组件来解决问题。
我认为上面的三部曲适用于任何组件或规范。

2018.12.15 三个问题

数据库#####

归纳问题 -> 定义解决方案 -> 实现解决方案

一、事务的四个特性
1.原子性（TODO 与多线程中的原子性有何异同？？？）
事务是最小的执行单位，不允许分割。保证包含的所有操作要么全部成功，要么全部失败回滚。
2.一致性
一个事务执行前后数据保持一致
拿转账来说，A和B账户总共有100块 中间无论怎么转账，转几次，最终A和B的账户总额还是100块。
3.隔离性
多个事务并发访问数据库时，一个事务不被其他事务干扰，并发事务之间的数据是独立的。
4.持久性
一个事务被提交后，对数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

二、四种隔离级别

并发访问数据库可能会出现的问题
脏读
一个事务读取到了另一个事务没有提交的数据（还在内存中，因为有可能会被回滚，所以是脏数据？）

不可重复读
在同一个事务中，两次读取同一个数据，得到内容不同（数据被其他事务修改并提交了）

幻读
在同一个事务中，用同样的操作读取两次，得到的记录数不相同（其他事务插入了新数据）

不可重复读和幻读表面上都是两次读到的数据不一致问题，
前者更侧重于针对同一条数据 内容不一致
同样的条件，两次读取到的结果集数量不一致

数据库定义了四种事务隔离机制来保证避免以上某种或者多种问题
1.READ_UNCOMMITTED 未提交读 最低的隔离级别，允许读取尚未提交的数据变更。可能会导致脏读、幻读或不可重复读
上面的问题一个都不能保证不出现

2.READ_COMMITTED 已提交读 只能保证不出现脏读 后面两种问题不能保证不出现

3.REPEATABLE_READ 保证不出现脏读和不可重复读 但是不能保证不出现幻读

4.SERIALIZABLE 串行化 可以保证不出现上面任何一种问题

上面只是定义了四种隔离级别来保证一个或多个问题不再出现 下面学习数据库为了实现这四种隔离级别
语义所采用的方案
其实数据库事务隔离级别的实现是采用锁机制
本质上只定义了两种锁
排它锁 -Exclusive Lock 简称X锁 写操作是需要获取
共享锁 -Share Lock 简称S锁 读操作时需要获取
只有SS锁是共存的 另一个角度来讲 只要有X锁存在 其他事务就不能获取任何锁了

从锁粒度维度 可以分为行级锁 间隙锁 表级锁

一级封锁协议 READ_UNCOMMITTED
不管是读操作还是写操作 都只获取共享锁 并且操作完就立即释放
上面三个问题一个都没有解决 多次一举 加锁有什么意义

二级封锁协议 READ_COMMITTED
读取操作 对数据加共享锁 读取完成之后立即释放 写操作，对数据加排它锁，事务结束之后（提交或者回滚）才释放锁
这样可以解决脏读，因为事务在提交后才会释放排它锁 其他事务才有机会来读取（这时已被提交）

TODO 但是不能避免不可重复读或者幻读 原因在于读操作完成之后会立即释放共享锁 这个时候其他事务就可以获取排它锁对
TODO 当前数据进行修改 等提交后 当前事务又可以再次获取共享锁 这时数据已被修改 出现了不可重复读问题 幻读类似

三级封锁协议 REPEATABLE_READ
加锁的方式跟二级封锁协议一致 不同点在于共享锁在事务完成之后才释放 这样在当前事务期间 数据不会被其他事务修改
但是这样依旧不能避免幻读问题 解决方案加间隙锁

最强封锁协议 SERIALIZABLE
对操作的数据整张表加锁 这样保证了同一张表的数据任意时刻只能被一个事务操作 以上所以问题都不再存在
但是这样的隔离级别会严重降低数据库的吞吐能力 所以数据库（MySQL默认的隔离级别是可重复读）

三、事务的传播行为 PROPAGATION 为了解决业务层方法之间相互调用的事务问题
支持当前事务
PROPAGATION_SUPPORTS 如果存在 则加入 不存在 则以非事务方式继续运行 （很随意 有就用 没有拉倒）
PROPAGATION_REQUIRED 如果调用方法存在事务，则加入当前事务，如果没有，则新建事务（好说话 没有就自己创建）
PROPAGATION_MANDATORY 如果存在 加入当前事务 如果不存在 抛出异常 （强硬 必要要在事务中运行）

不支持当前事务
PROPAGATION_REQUIRES_NEW 自己创建新的事务 如果当前已经有了 则挂起 （有点原则 一定要用自己的）
PROPAGATION_NOT_SUPPORTED 以非事务方式运行 如果当前存在事务 则挂起（有点原则 反正自己不用）
PROPAGATION_NEVER 以非事务方式运行 如果当前存在事务 则抛出异常（怪异 死活不用）

其他情况
PROPAGATION_NESTED 如果当前存在事务 则创建一个事务作为档期内事务的嵌套事务来运行；如果当前没有事务，等价于REQUIRED
TODO 什么叫等价于？ 没有的话新建一个事务 跟嵌套不嵌套有什么区别？

四、引擎
InnoDB
1.具有事务、回滚、崩溃修复能力的事务安全型表
2.支持外键
3.支持行级锁
4.不支持全文索引

MyISAM
1.不支持事务
2.不支持外键
3.只支持表级锁
4.支持全文索引

MySQL默认引擎是InnoDB

五、索引
https://www.kancloud.cn/kancloud/theory-of-MySQL-index/41855

加快查询的一种数据结构
顺序查找 二分查找 二叉树查找

TODO B+树详解？？？？

MySQL大表优化方案 ***
https://segmentfault.com/a/1190000006158186