关系型数据库的优点
非关系型数据库（NOSQL）的优点
根本原因
扩展
三种常见的索引底层数据结构：分别是哈希表、有序数组和搜索树。
根据叶子节点的内容，索引类型分为主键索引和非主键索引。
Server 层按顺序执行 SQL 的步骤为：
两个考虑因素：
为什么选择 B+ 树：
覆盖索引：
索引下推：
第一点：redo log 可确保 innoDB 判断哪些数据已经刷盘，哪些数据还没有
第二点：如果 redo log 写入失败，说明此次操作失败，事务也不可能提交
根据 redo log 和 binlog 的两阶段提交，未持久化的数据分为几种情况：
redo log包括两部分内容，分别是内存中的日志缓冲(redo log buffer)和磁盘上的日志文件(redo log file)。
MySQL 每执行一条 DML 语句，会先把记录写入 redo log buffer（用户空间） ，再保存到内核空间的缓冲区 OS-buffer 中，后续某个时间点再一次性将多个操作记录写到 redo log file（刷盘） 。这种先写日志，再写磁盘的技术，就是WAL。
可以发现，redo log buffer写入到redo log file，是经过OS buffer中转的。其实可以通过参数innodb_flush_log_at_trx_commit进行配置，参数值含义如下：
我们来看下Redo log的执行流程，假设执行的 SQL 如下：
MySQL 将 redo log 的写入拆成了两个步骤：prepare 和 commit，中间再穿插写入binlog，这就是"两阶段提交"。
而两阶段提交就是让这两个状态保持逻辑上的一致。redolog 用于恢复主机故障时的未更新的物理数据，binlog 用于备份操作。两者本身就是两个独立的个体，要想保持一致，就必须使用分布式事务的解决方案来处理。
为什么需要两阶段提交呢?
在恢复数据时，redolog 状态为 commit 则说明 binlog 也成功，直接恢复数据；如果 redolog 是 prepare，则需要查询对应的 binlog事务是否成功，决定是回滚还是执行。
一个事务的 binlog 是有完整格式的：
WAL，中文全称是 Write-Ahead Logging，它的关键点就是日志先写内存，再写磁盘。MySQL 执行更新操作后，在真正把数据写入到磁盘前，先记录日志。
好处是不用每一次操作都实时把数据写盘，就算 crash 后也可以通过redo log 恢复，所以能够实现快速响应 SQL 语句。
数据库在某个时候误操作，就可以找到距离误操作最近的时间节点的bin log，重放到临时数据库里，然后选择误删的数据节点，恢复到线上数据库。
binlog 日志有三种格式
Statement格式
每一条会修改数据的 SQL 都会记录在 binlog 中
Row格式
不记录 SQL 语句上下文相关信息，仅保存哪条记录被修改。
Mixed格式
实际上就是 Statement 与 Row 的结合。一般的语句修改使用 statment 格式保存 binlog，如一些函数，statement 无法完成主从复制的操作，则采用 row 格式保存 binlog，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式。
在阅读过程中，有任何问题都可以问小贺，欢迎交流，一起成长！
觉得不错的小伙伴，记得帮我 @herongwei 点个赞哟，笔芯~~
