在具体执行SQL语句之前，要先经过优化器的处理
– 当表中有多个索引的时候，决定用哪个索引
– 当sql语句需要做多表关联的时候，决定表的连接顺序
不同的执行方式对SQL语句的执行效率影响很大
– RBO:基于规则的优化
– CBO:基于成本的优化(性能相关)
mysql日志:
binlog(主从复制是基于此)：数据库的server
这两个日志保证InnoDb引擎支持事务
redo log:(重做日志)
Redo log—innodb存储引擎的日志文件：保证数据一致性（保证数据不丢失）
当发生数据修改的时候，innodb引擎会先将记录写到redo log中，
并更新内存，此时更新就算是完成了，同时innodb引擎会在合适的时机将记录操作到磁盘中
▪ Redolog是固定大小的，是循环写的过程
▪ 有了redolog之后，innodb就可以保证即使数据库发生异常重启，之前的记录也不会丢失，叫做crash-safe
undo log(保证A,与回滚相关，原子性)：保证事务的原子性(为回滚而生，保证原子性)
Undo Log是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，
还用Undo Log来实现多版本并发控制(简称：MVCC)
▪ 在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方
称为Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了
ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之
前的状态
▪ 注意：undo log是逻辑日志，可以理解为：也就是回滚到之前的状态
– 当delete一条记录时，undo log中会记录一条对应的insert记录
– 当insert一条记录时，undo log中会记录一条对应的delete记录
– 当update一条记录时，它记录一条对应相反的update记录
MYISAM不支持事务，也就没有上面两种日志
binlog—服务端的日志文件
mysql 的binlog日志默认是关闭的
▪ Binlog是server层的日志，主要做mysql功能层面的事情
▪ 与redo日志的区别:
– 1、redo是innodb独有的，binlog是所有引擎都可以使用的
– 2、redo是物理日志，记录的是在某个数据页上做了什么修改，binlog是逻
辑日志，记录的是这个语句的原始逻辑(包括数据和sql语句)
– 3、redo是循环写的，空间会用完，binlog是可以追加写的，不会覆盖之前
的日志信息
Binlog(恢复数据)中会记录所有的逻辑，并且采用追加写的方式
▪ 一般在企业中数据库会有备份系统，可以定期执行备份，备份的周期可以自己设置
▪ 恢复数据的过程：
– 1、找到最近一次的全量备份数据
– 2、从备份的时间点开始，将备份的binlog取出来，重放到要恢复的那个时刻
为什么要分2阶段端提交？
保证数据库的一致性
Redo log(保证数据一定会保存,保证D持久性)的两阶段提交
▪ 先写redo log后写binlog:假设在redo log写完，binlog还没有写完的时候，MySQL进程
异常重启。由于我们前面说过的，redo log写完之后，系统即使崩溃，仍然能够把数据恢复
回来，所以恢复后这一行c的值是1。但是由于binlog没写完就crash了，这时候binlog里面
就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。
然后你会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这
个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。
▪ 先写binlog后写redo log:如果在binlog写完之后crash，由于redo log还没写，崩溃恢复
以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了“把c从0改成1”这个
日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值
就是1，与原库的值不同。
undo log和redo log 最终都是为了保证C(一致性)
