优化

1. 定位慢查询

怎么找出执行慢的sql？

如果是index 或是 all，则需要优化sql。

2. 索引

使用explain判断索引失效：

原因是进行了自动的类型转换，原本status应该是string，不加单引号会将数字0转化成字符0，类型转换会导致索引失效。

3. sql优化经验

事务相关

隔离级别从上往下安全性越高，但性能越差！



如果没有出现服务器宕机，buffer pool的脏页数据可以正常同步到磁盘是，redo log就不发挥作用。每隔一段时间redo log file就定期清理，磁盘中有两份，循环写。

WAL（write ahead logging）：在数据本身的修改被持久化到磁盘之前，必须先确保描述这些修改的日志记录已经持久化到磁盘。换句话说：先写日志，后写数据。

用快速的顺序I/O（Redo Log）来保证事务的持久性，而将慢速的随机I/O（数据页刷盘）推迟到后台异步进行，从而在保证数据安全的同时大幅提升性能。

summary：当出现问题时使用redo log恢复，保证数据的持久性！此时的流程为：
事务开始–>在内存中修改数据页–>生成redo log记录–>redo log强制刷盘fsync–>返回事务提交成功–>后台异步刷脏页到磁盘数据页。

undo log工作流程：事务开始–>数据修改前将相反操作写入undo log–>在内存buffer pool中修改数据–>是否提交？–>是：标记undo log可以清理–>否？用undo log回滚到旧数据。
redo log：保证事务的持久性；undo log：保证事务的原子性和一致性。 持久性：事务一旦提交，它对数据库的修改就是永久性的，即使发生系统崩溃也不会丢失。由上文可以，发生崩溃可以根据redo log file来进行崩溃前的恢复：找到最后一个Checkpoint，重放从Checkpoint之后的所有Redo Log。

原子性：事务中的所有操作要么全部完成，要么全部不完成，不可能停留在中间状态。 一致性：事务必须使数据库从一个一致性状态变换到另一个一致性状态。因此当系统崩溃时，可以使用undo log回滚所有没有commit的事务！

完整的崩溃恢复流程：

1. redo log重做已提交的操作；
2. undo log回滚未提交的操作。

MVCC

事物的隔离性如何保证？





当前读：对扫描的数据加锁–>等待持有该数据锁的事务释放锁–>获取锁成功–>读取数据的最新版本。

快照读：确定read view–>遍历每行数据–>检查行的事务id–>事务id<read view创建时间且已提交，则该行可见–>事务id>创建时间或未提交，则该行不可见，沿着undo链找到旧版本–>返回可见的行。

MySql主从同步原理

分库分表