数据库事务、锁与设计原理
文章目录
- 事务
- ACID特性
- 原子性（Atomicity）
- 一致性（Consistency）
- 隔离性（Isolation）
- 持久性（Durability）
- 理解
- 隔离级别
- 未提交读（READ UNCOMMITTED）
- 提交读（READ COMMITTED）
- 可重复读（REPEATABLE READ）
- 可串行化（SERIALIZABLE）
- 总结
- 锁
- 悲观锁
- 共享锁
- 排他锁
- 表锁
- 行锁
- 乐观锁
- 版本号机制
- CAS算法
- 两种锁的适用场景
- 关系型数据库设计
- 函数依赖
- 部分函数依赖
- 完全函数依赖
- 传递函数依赖
- 范式
- 第一范式（1NF）
- 第二范式（2NF）
- 第三范式（3NF）
- ER图
- 参考资料
事务
事务是指满足ACID特性的一组操作，它们要么完全地执行，要么完全地不执行。
ACID特性
原子性（Atomicity）
一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚。
一致性（Consistency）
数据库总是从一个一致性的状态转换到另外一个一致性状态。事务开始和结束之间的中间状态不会被其他事务看到。
隔离性（Isolation）
一个事务所作的修改在最终提交前，对其它事务是不可见的。
持久性（Durability）
一旦事务提交，则其所作的修改就会永久保存到数据库中。即使系统崩溃，修改的数据也不会丢失。
理解
事务的ACID特性概念简单，但不是很好理解，主要是因为这几个特性不是一种平级关系：
- 只要满足一致性，事务的执行结果才是正确的。
- 在无并发的情况下，事务串行执行，隔离性一定能够满足。此时只要满足原子性，就一定能满足一致性。
- 在并发的情况下，多个事务并行执行，事务不仅要满足原子性，还要满足隔离性，才能满足一致性。
- 事务满足持久化是为了能应对数据库崩溃的情况。
隔离级别
在并发环境下需要关注事务的隔离性，SQL标准中定义了以下四种隔离级别。
未提交读（READ UNCOMMITTED）
事务中的修改即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为脏读。
提交读（READ COMMITTED）
一个事务从开始直到提交之前，所做的任何修改对其它事务都是不可见的。
这个级别有时候也叫做不可重复读，因为两次执行同样的查询，可能会得到不一样的结果。例如，T2读取一个数据，T1对该数据做了修改并提交，如果T2再次读取这个数据，那么读取的结果和第一次读取的结果不同。
可重复读（REPEATABLE READ）
可重复读保证了在同一事物中多次读取同样记录的结果是一致的。
该级别无法解决幻读问题，即当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行。
可串行化（SERIALIZABLE）
该级别是最高的隔离级别，通过强制事务串行执行避免上面的幻读问题。
总结
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | 加锁读 |
|---|---|---|---|---|
| 未提交读 | √ | √ | √ | × |
| 提交读 | × | √ | √ | × |
| 未提交读 | × | × | √ | × |
| 未提交读 | × | × | × | √ |
锁
当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。所以，锁主要用于处理并发问题。
从数据库系统角度分为三种：排他锁、共享锁、更新锁。
从程序员角度分为两种：一种是悲观锁，一种乐观锁。
悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
传统的关系数据库里用到了很多这种锁机制，比如按使用性质划分的读锁、写锁和按作用范围划分的行锁、表锁。
共享锁
共享锁（S锁）又称为读锁，若事务T对数据对象A加上S锁，则事务T只能读A；其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
排他锁
排他锁（X锁）又称为写锁，若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。
表锁
每次操作锁住整张表，开销小，加锁快，锁粒度大，发生锁冲突的概率最高，并发度最低。
行锁
每次操作锁住一行数据，开销大，加锁慢，锁粒度小，发生锁冲突的概率最低，并发度最高。
数据库能够确定哪些行需要锁的情况下使用行锁，如果不知道会影响哪些行的时候就会使用表锁。
乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。
版本号机制
一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值与当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
CAS算法
CAS即compare and swap（比较并交换），是一种有名的无锁算法，在不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步。CAS算法涉及到三个操作数：
- 要更新的变量V
- 预期的值E
- 新值N
仅当V值等于E值时，才会将V的值设置成N，否则什么都不做。最后CAS返回当前V的值。CAS算法需要你额外给出一个期望值，也就是你认为现在变量应该是什么样子，如果变量不是你想象的那样，就说明已经被别人修改过，就重新读取，再次尝试修改即可。
因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时就会误以为它的值没有发生变化，这个问题称为ABA问题。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A-B-A就会变成1A-2B-3A，以此来防止不恰当的写入。
两种锁的适用场景
乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行重试，这样反倒是降低了性能，所以一般多写的场景下用悲观锁比较合适。
关系型数据库设计
函数依赖
部分函数依赖
设X、Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。
完全函数依赖
设X、Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’ !→Y，则称Y完全函数依赖于X。
传递函数依赖
设X、Y、Z是关系R中互不相同的属性集合，存在X→Y（Y !→X），Y→Z，则称Z传递函数依赖于X。
范式
第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列（每个属性）都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之，第一范式就是无重复的列。
第二范式（2NF）
第二范式（2NF）要求实体的属性完全依赖于主关键字。
第三范式（3NF）
在满足第二范式的基础上，且不存在传递函数依赖，那么就是第三范式。简而言之，第三范式就是属性不依赖于其它非主属性。
ER图
ER图由三个部分组成：实体、属性、联系。
参考资料
- CS-NOTE
- 数据库锁分类和总结
- 面试必备之乐观锁与悲观锁
- 并发策略-CAS算法