关系型数据库和非关系型数据库的区别
在关系型数据库中，数据存储于一张张固定行列的表中；而非关系型数据库中，数据有文档、键值对、图、宽列等多种存储方式。
MySQL数据库
MyISAM和InnoDB存储引擎的区别
- MyISAM只能支持表级锁，InnoDB可以支持行级锁和MVCC；
- MyISAM不支持事务，InnoDB支持事务；
- MyISAM不支持数据库异常崩溃后安全恢复，InnoDB支持；
- 索引实现不一样；
- InnoDB在多核情况下读写能力呈线性增长；
- InnoDB支持外键（感觉无关紧要，毕竟现在尽量不用外键了）
事务
事务是逻辑上的一组操作，要么都执行，要么都不执行
用事务的原子性，隔离性和持久性来保证数据的一致性。
并发事务带来的问题
- 脏读
- 丢失更改
- 不可重复读
- 幻读
并发事务的控制方式
通过锁或者MVCC来避免并发事务带来的问题。
锁
- 共享锁：读锁，事务在读取记录的时候获取共享锁，允许多个事务读取时也获取；
- 排他锁：写锁/独占锁。
MVCC（多版本并发控制方法）
对一份数据会存储多个版本，通过事务的可见性来保证事务能看到自己应该看到的版本。
MVCC 在 MySQL 中实现所依赖的手段主要是: 隐藏字段、read view、undo log。
事务隔离级别
- 读取未提交
- 读取已提交
- 可重复读
- 可串行化
索引
常见索引列建议
- 出现在 SELECT、UPDATE、DELETE 语句的 WHERE 从句中的列
- 包含在 ORDER BY、GROUP BY、DISTINCT 中的字段
- 不要将符合 1 和 2 中的字段的列都建立一个索引， 通常将 1、2 中的字段建立联合索引效果更好
- 多表 join 的关联列
如何选择索引列的顺序
- 区分度高的放到联合索引的最左侧
- 字段长度小的放到联合索引的最左侧
- 使用最频繁的列放到联合索引最左侧
索引的优缺点
优点：在数据量大的情况下，索引能提高查询速度；通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性
缺点：创建索引需要耗费时间，影响插入效率；索引也是数据文件，占用存储空间
索引结构
在InnoDB中，主索引的键是主键，叶子节点的数据就是该条记录，其他索引叶子节点的数据是主键值。因此，使用辅助索引查到的只是主键值，还要再走一遍主索引才能拿到数据。
MyISAM 引擎中，B+Tree 叶节点的 data 域存放的是数据记录的地址。在索引检索的时候，首先按照 B+Tree 搜索算法搜索索引，如果指定的 Key 存在，则取出其 data 域的值，然后以 data 域的值为地址读取相应的数据记录。这被称为“非聚簇索引（非聚集索引）”。
InnoDB 引擎中，其数据文件本身就是索引文件。相比 MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按 B+Tree 组织的一个索引结构，树的叶节点 data 域保存了完整的数据记录。这个索引的 key 是数据表的主键，因此 InnoDB 表数据文件本身就是主索引。这被称为“聚簇索引（聚集索引）”，而其余的索引都作为 辅助索引 ，辅助索引的 data 域存储相应记录主键的值而不是地址，这也是和 MyISAM 不同的地方。在根据主索引搜索时，直接找到 key 所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。
联合索引和覆盖索引的区别
使用表中的多个字段创建索引，就是 联合索引，也叫 组合索引 或 复合索引。
覆盖索引即需要查询的字段正好是索引的字段，那么直接根据该索引，就可以查到数据了，而无需回表查询。
聚簇索引
索引和数据放在一起的就是聚簇索引，优点是无需回表查询。
索引失效
- 使用
SELECT *进行查询; - 创建了组合索引，但查询条件未准守最左匹配原则;
- 在索引列上进行计算、函数、类型转换等操作;
- 以
%开头的 LIKE 查询比如like '%abc'; - 查询条件中使用 or，且 or 的前后条件中有一个列没有索引，涉及的索引都不会被使用到;
- 发生隐式转换
MySQL日志
二进制日志 binlog（归档日志），事务日志 redo log（重做日志）和 undo log（回滚日志）
redo log(重做日志）
redo log（重做日志）是InnoDB存储引擎独有的，它让MySQL拥有了崩溃恢复能力。
比如 MySQL 实例挂了或宕机了，重启时，InnoDB存储引擎会使用redo log恢复数据，保证数据的持久性与完整性。
执行时机
每次更新数据时都将更新信息记录到重做日志缓存中，然后当事务提交后，使用默认策略将缓存写到硬盘中的重做日志中。
存储形式
硬盘上存储的 redo log 日志文件不只一个，而是以一个日志文件组的形式出现的，每个的redo日志文件大小都是一样的。比如可以配置为一组4个文件，每个文件的大小是 1GB，整个 redo log 日志文件组可以记录4G的内容。
它采用的是环形数组形式，从头开始写，写到末尾又回到头循环写，
bin log(归档日志）
逻辑日志，记录语句的原始逻辑，用来数据备份，主从复制等。
记录格式
- statement: 记录的内容是SQL语句原文
- row: 记录的内容不再是简单的SQL语句了，还包含操作的具体数据。为了解决语句中包含now()之类语句而产生的数据不一致。
- mixed 混合形式，仅在需要实时计算的地方采用row。
执行时机
- 事务执行过程中，先把日志不断写到binlog cache，事务提交的时候，再把binlog cache合并后写到binlog文件中。
- 二进制日志仅在事务提交时记录，并且对于每一个事务，仅包含对应事务的一个日志
- 重做日志其记录的物理操作日志，因此每个事务对应多个日志条目，并且事务的重做日志写入是并发的，并非在事务提交时写入，故其在文件中记录的顺序并非是事务开始的顺序（下图中带有*的，意为该事务的提交）
两阶段提交
在事务执行过程中记录的redo log不会直接提交，而是进入prepare预备阶段，等事务执行完毕且bin log写入后，再将redo log转为commit阶段。
undo log(回滚日志）
- 当事务回滚时用于将数据恢复到修改前的样子
- 另一个作用是 MVCC ，当读取记录时，若该记录被其他事务占用或当前版本对该事务不可见，则可以通过 undo log 读取之前的版本数据，以此实现非锁定读
总结
MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。MySQL数据库的数据备份、主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。
