mysql 合集

mysql 日志主要分为三个日志：redo log、binlog、undo log;

redo log 主要是用来mysql 奔溃恢复

redo log 主要是有一个机制是 设置刷盘机制：
通过innodb_flush_log_at_trx_commit控制刷盘策略：
=1：每次事务提交都刷盘（默认，最安全）。
=0：每秒刷盘（可能丢失1秒数据）。
=2：写入文件系统缓存，不强制刷盘（依赖操作系统）
为什么要加这个日志，直接写到磁盘不好嘛？
io操作是随机操作，redo log 写入是顺序的减少消耗
在数据恢复时候即使没有写到磁盘中，也可以利用 redo log 进行重放恢复

binlog 是用来记录mysql 表数据更新的 主要用来 同步数据

binlog 会记录所有涉及更新数据的逻辑操作，并且是顺序写;
一般都是先到 binlog cache 然后到 bin log文件 然后写入磁盘
其中有个重要参数控制啥时候去写入到磁盘（sync_binlog）
为0的时候，表示每次提交事务都只write(操作系统的缓存)，由系统自行判断什么时候执行fsync
为1的时候，表示每次提交事务后执行 fsync（写到 bin log 和 系统磁盘）
为N(N>1)的时候，表示每次提交事务后在系统缓存写到 N个事务后 执行 fsync（写到 bin log 和 系统磁盘）

两阶段提交

binlog 是事务提交后写入 redo log 是事务在执行时候一直写入，当事务没提交时候 redolog 里面记录状态为 perpare ，当事务提交后写如bin log 并更新redo log 为 commit;

​崩溃恢复逻辑：
若 Redo Log 为 Commit 状态：事务必须提交。
若 Redo Log 为 Prepare 状态：
检查 Binlog 是否存在对应事务的日志：
​存在 → 提交事务（重放 Redo Log）。
​不存在 → 回滚事务（通过 Undo Log）

undo log(回滚日志) 来保证事务的原子性

执行一句更新操作 会在undo log保存数据修改前的旧版本；

sql 优化面试

1. explain 执行计划

其中主要的列有：id、type、key、extra
id 没啥好说的：越大越先被执行，如果一样从上到小顺序执行
type: 主要分为下面几个级别（按照顺序由好到坏）：
1）system(这个我没遇到过)
2）const(一般查询结果最多有一条，一般主键索引或者唯一索引的所有字段作为查询条件时候)
3）eq_ref(一般是连表查询时候，前表行和后面连表的行一一对应时候，一般是主键索引或者唯一索引的所有字段作为连表条件时候)
4）ref(是一般查询走了普通索引时候)
5）range(对索引列进行了范围查找)、ALL(全表扫描了)
key: 代表这次查询用用到的索引
extra：表示这次查询用到的额外信息
1）use filesort(用到了额外的步骤进行了排序，没用用到表内的索引)
2）use temporary (mysql 用到了临时表，常见与order by 和 group by)
3) use index(表示用到了索引覆盖，不需要回表效率高)
4)use index condition (表示用到了索引条件下推)==》索引条件下推：如果联合索引中，查询条件中有一些命中 但是有一些没走到索引，mysql 优化器会采用索引下推，在引擎层 对没走上索引但是在索引里面的条件进行提前筛选然后回表，返回给应用层；如果没开启，就会将走了索引的满足条件的所有数据进行回表，然后返回再筛选，增多了回表数据。
5）use where（一般是对没有走了索引的字段进行了筛选）
其中 如果 extra 出现了 use filesort 或者 use temporary 时候表示sql 存在优化空间，应该尽量避免！！

2. mysql 的隐式转换

一般就是 字符串 转 数字 或者就是 数字 转 字符串 其中有三个特性：
1）字符串转数字时候对 mysql 效率没有影响 如果有索引还是会走的。
2）数字转字符串时候 影响很大 导致不会走索引 全表扫描
3）字符串转数字时候 如果字符串是以字符开头 mysql 会转为 0 ，如果 是以数字开头 则是从数字到后面第一个不是数字为止！
例子：num 是数字型的 如果是 num=‘ab123’ 表示 num=0 如果 num=‘123bbb’ 表示 num=123