一、事务

事务指的是满足ACID的一组操作，它可以通过Commit提交一个事务，也可以使用Rollback进行回滚。

  1. 原子性（Atomicity）

    事务被视为不可分割的最小单元，事务的所有操作要么全部完成后提交，要么全部失败回滚。

    回滚可以通过回滚日志（Undo log）实现，里面记录着事务所执行的所有修改操作，回滚时反向执行即可。

  2. 一致性（Consistency）

    数据库在事务执行前后都保持一致性状态。在一致性状态下，所有事务对同一个数据的读取结果是相同的。

  3. 隔离性（Isolation）

    一个事务所作的更改在提交前对其他事务是不可见的。

  4. 持久性（Durability）

    一旦事务提交，其所作的更改就会永远保持到数据库中。即使数据库发生崩溃，事务的执行的结果也不能丢失。

    系统发生崩溃时，可以通过重做日志（Redo Log）进行修复，从而实现持久性。与回滚日志不同记录的数据的逻辑修改不同，重做日志记录的是数据页的物理更改。

事务的ACID特性概念简单，但不好理解，主要是这几个特性不是一种平级关系：

  • 一致性是基本保证的，只有满足一致性，事务的执行结果才是正确的
  • 在无并发情形下，事务串行执行，隔离性一定满足。此时只要满足原子性就能满足一致性
  • 在并发情形下，多个事务并发执行，事务不仅要满足原子性，还要满足隔离性，才能满足一致性
  • 事务满足持久性，是为了应对系统崩溃情况

二、并发一致性问题

并发条件下，事务的隔离性很难保证，因为会出现很多并发一致性问题。

  1. 丢失修改

    T1，T2两个事务都对一个数据进行修改，T1先修改，T2后修改，此时T2的修改会覆盖T1的修改。

丢失修改

  1. 读脏数据

    T1修改一个数据，T2随后读取了该数据。如果T1撤销了这次修改（发生了回滚），那么T2读到的数据是脏数据。

    读脏数据

  2. 不可重复读

    T2读取了一个数据，随后T1修改了该数据。如果T2再次读该数据，此时读取的数据与第一次不一致。

    不可重复读

  3. 幻读

    T1读取了某个范围内的数据，随后T2在这个范围内插入了一条数据。T1再次查询这个范围内的数据的话，此时读取的结果与第一次不同。

    幻读

三、数据库中的锁机制

  1. 锁的粒度

    MySQL中提供了两种锁的粒度：行级锁和表级锁。

    降低锁的粒度，可以减少锁的竞争，提升系统的并发程度。

    但是加锁需要消耗资源，锁的各种实现都会增加系统负担。锁粒度越小，系统开销越大。

    因此需要平衡锁开销和并发度。

  2. 锁的类型

    独占锁（Exclusive），简写为 X 锁，又称写锁。

    共享锁（Shared），简写为 S 锁，又称读锁。

    有以下两个规定：

    ​ 一个事务对数据对象 A 加了 X 锁，就可以对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何锁。

    ​ 一个事务对数据对象 A 加了 S 锁，可以对 A 进行读取操作，但是不能进行更新操作。加锁期间其它事务能对 A 加 S 锁，但是不能加 X 锁。

    补充（不太懂）

    使用意向锁（Intention Locks）可以更容易地支持多粒度封锁。

    在存在行级锁和表级锁的情况下，事务 T 想要对表 A 加 X 锁，就需要先检测是否有其它事务对表 A 或者表 A 中的任意一行加了锁，那么就需要对表 A 的每一行都检测一次，这是非常耗时的。

    意向锁在原来的 X/S 锁之上引入了 IX/IS，IX/IS 都是表锁，用来表示一个事务想要在表中的某个数据行上加 X 锁或 S 锁。有以下两个规定：

    ​ 一个事务在获得某个数据行对象的 S 锁之前，必须先获得表的 IS 锁或者更强的锁；

    ​ 一个事务在获得某个数据行对象的 X 锁之前，必须先获得表的 IX 锁。

    通过引入意向锁，事务 T 想要对表 A 加 X 锁，只需要先检测是否有其它事务对表 A 加了 X/IX/S/IS 锁，如果加了就表示有其它事务正在使用这个表或者表中某一行的锁，因此事务 T 加 X 锁失败。

  3. 封锁协议

    一级封锁协议：事务 T 要修改数据 A 时必须加 X 锁，直到 T 结束才释放锁。

    可以解决丢失修改问题，因为不能同时有两个事务对同一个数据进行修改，那么事务的修改就不会被覆盖。

    二级封锁协议：在一级的基础上，要求读取数据 A 时必须加 S 锁，读取完马上释放 S 锁。

    可以解决读脏数据问题，因为如果一个事务在对数据 A 进行修改，根据 1 级封锁协议，会加 X 锁，那么就不能再加 S 锁了，也就是不会读入数据。

    三级封锁协议：在二级的基础上，要求读取数据 A 时必须加 S 锁，直到事务结束了才能释放 S 锁。

    可以解决不可重复读的问题，因为读 A 时，其它事务不能对 A 加 X 锁，从而避免了在读的期间数据发生改变。

    两端锁协议：加锁和解锁分为两个阶段进行。

    可串行化调度是指，通过并发控制，使得并发执行的事务结果与某个串行执行的事务结果相同。串行执行的事务互不干扰，不会出现并发一致性问题。

    事务遵循两段锁协议是保证可串行化调度的充分条件，但不是必要条件。

四、事务的隔离级别

  1. 读未提交（READ UNCOMMITTED）

    一个事务可以读取到另一个事务没有提交的数据。无法避免任何一种情况。

  2. 读提交（READ COMMITTED）

    一个事务只能读取已经提交的事务所做的修改。换句话说，一个事务所做的修改在提交之前对其它事务是不可见的。可以解决脏读。

  3. 可重复读（REPEATABLE READ）

    保证在同一个事务中多次读取同一数据的结果是一样的。可以解决不可重复读。

  4. 序列化（SERIALIZABLE）

    强制事务串行执行，这样多个事务互不干扰，不会出现并发一致性问题。

    该隔离级别需要加锁实现，因为要使用加锁机制保证同一时间只有一个事务执行，也就是保证事务串行执行。

五、多版本并发控制

六、关系数据库设计理论

数据库三大范式：

  • 属性不可分：每一列属性都是不可再分的属性值，确保每一列的原子性，两列属性相近或一样，尽量合并属性一样的列，确保不产生冗余数据。
  • 每一行的数据只能与其中一列相关，一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。
  • 数据不能存在传递关系，每个属性都与主键有直接关系而不是间接关系。

七、常见问题

  1. 数据库索引用过哪些，什么情况失效？

    主键索引（聚簇索引）、普通索引、唯一索引、全文索引

    where 语句中使用or，但是没有把or中的所有字段都加上索引，索引失效。

　　where 语句使用<>和!=

　　like查询以“%…”开头

　　如果mysql估计全表扫描更快的话

  1. LIMIT M, N

    LIMIT 给定两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数目（初始记录行的偏移量是 0而不是 1)。

    LIMIT M 等价于LIMIT 0, M

  2. drop和delete的区别

    delete 删除的是 数据，drop语句删除表结构及所有数据，并将表所占用的空间全部释放

　　delete会触发触发器，drop不会触发触发器；

  1. 数据库事务的应用场景

    在执行一系列数据库操作时，要保证这些操作必须完全正确执行，否则就不执行，在这种情况下，适合使用事务，例如将一些数据插入到两个相关联的表中，而且不能只有一张表插入成功，这种情况下，使用事务，无论是否插入成功，都不会对数据库造成不好的影响。

  2. 数据库索引的创建原则

    表的主键、外键必须有索引;

    经常查询的数据列最好建立索引

    对于需要在指定范围内的快速或频繁查询的数据列;

    经常用在WHERE子句中的数据列。

    经常出现在关键字order by、group by、distinct后面的字段，建立索引。如果建立的是复合索引，索引的字段顺序要和这些关键字后面的字段顺序一致，否则索引不会被使用。