【java】mysql
优化
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的事务！
完整的崩溃恢复流程：
- redo log重做已提交的操作；
- undo log回滚未提交的操作。
MVCC
事物的隔离性如何保证？
当前读：对扫描的数据加锁–>等待持有该数据锁的事务释放锁–>获取锁成功–>读取数据的最新版本。
快照读：确定read view–>遍历每行数据–>检查行的事务id–>事务id<read view创建时间且已提交，则该行可见–>事务id>创建时间或未提交，则该行不可见，沿着undo链找到旧版本–>返回可见的行。
MySql主从同步原理
分库分表
