- 1. MySQL主从复制的原理。
- 2. Seconds_Behind_Master的原理。
- 3. 主从延迟的主要原因有哪些？
- 4. MySQL常见存储引擎及各自特点。
- 5. innodb_flush_log_at_trx_commit参数0、1和2分别代表什么？
- 6. Mysql中varchar和char的区别
- 7. varchar(50)中的50代表的含义、int(20)中20的含义。
- 8. MySQL binlog的几种日志录入格式的涵义、适用场景和在复制中的优劣。
- 9. 重做日志和二进制日志的区别（至少三点）
- 10. Explain执行计划中要关注哪些要素？
1. MySQL主从复制的原理。
- 主库必须开启二进制日志
- 当有增删改的语句时，会记录到主库的binlog中
- 主库通过IO线程把binlog里面的内容传给从库的relay binlog（中继日志）（这是msyql复制是异步复制的原因）
- 从库的sql线程负责读取它的relay log里的信息并应用到数据库中
2. Seconds_Behind_Master的原理。
表示sql线程和io线程之间的时间差
具体的计算：从库服务器当前的时间戳与二进制日志中的事件的时间戳相对比得到的，所以只有在执行事件时才能报告延迟。 不足：
一些错误（例如主备的max_allowed_packet不匹配，或者网络不稳定）可能中断复制，由于主从复制是异步操作，Seconds_Behind_Master可能显示为0
3. 主从延迟的主要原因有哪些？
- 慢SQL语句过多
- 从库的硬件比主库差
- 同一个主库下有过多的从库
- 网络延迟
- 表分区过多
- 主库执行比较大的事务
- 主库对比较大数据进行执行增删改
4. MySQL常见存储引擎及各自特点。
| 引擎 | 特点 |
|---|---|
| InnoDB | 支持事务、行级锁、支持外键约束，主要面向OLTP的应用，使用next-key locking 的策略来避免幻读现象的产生. |
| MyISAM | 不支持事务、表锁设计、支持全文索引、读写互相阻塞、不支持外键约束；主要面向OLAP应用场景；缓存池只缓存索引文件，不缓存数据文件 |
| Memory | 将所有数据保存在RAM中，在需要快速查找引用和其他类似数据的环境下，可提供极快的访问。如果数据库重启或者奔溃，数据都将丢失。 |
| TokuDB | 支持事务、高压缩、告诉读写、基于稀疏树索引设计；支持大多数在线修改索引、添加字段。 |
| Inforbright/infinidb | 列式存储、高压缩、单列查询快 |
5. innodb_flush_log_at_trx_commit参数0、1和2分别代表什么？
innodb_flush_log_at_trx_commit参数可以控制将redo log buffer中的更新记录写入到日志文件以及日志文件刷新到磁盘的操作时机。
| 值 | 解释 |
|---|---|
| 0 | 每秒一次触发log buffer写入log file中，并且log file刷新到磁盘。（由于进程调度问题，不能保证每秒100%刷新；如果mysql进程崩溃，可能会丢失1s的事务；效率最高，但最不安全） |
| 1 | 每次事务提交触发log buffer写入log file中，并且log file刷新到磁盘。 |
| 2 | 每次事务提交，log buffer写入log file中；每秒log file刷新到磁盘。（如果操作系统崩溃或者停电，可能会丢失1s的事务） |
6. Mysql中varchar和char的区别
CHAR列的长度固定为创建表时声明的长度，范围（0-255）
VARCHAR列的长度不固定，范围（0-65535）
7. varchar(50)中的50代表的含义、int(20)中20的含义。
varchar(50)中的50代表最多能存放50个字符
int(20)中20的含义表示显示宽度，跟着zerofill一起才有意义
8. MySQL binlog的几种日志录入格式的涵义、适用场景和在复制中的优劣。
|模式|介绍|场景|优点|缺点|
|—|—|—|—|—|
|statement level模式|每一条会修改数据的sql都会记录到master的binlog中，slave在复制时sql进程会解析成和原来master端执行过的相同的sql再次执行。|对主从数据一致性要求不太高，并且很少用到函数、存储过程、触发器等场景|bin-log日志量少|部分新功能（函数、存储过程、触发器）同步会有障碍，比如now()|
|row level模式|日志中会记录成每一行数据被修改的形式，然后再slave端再对相同的数据进行修改|对主从数据一致性要求比较高的场景。|记录的详细|binlog日志量过大|
|mixed模式|MySQL默认采用statement格式进行二进制日志文件的记录，但是在一些情况下会使用row格式，可能的情况有：
1）、表的存储引擎为NDB，此时对表的DML操作都会以ROW格式记录
2）、使用了UUID(),USER(),CURRENT_USER(),FOUND_ROWS(),ROW_count()等不确定函数时
3）、使用了insert delay语句
4）、使用了用户定义函数（UDF）
5）、使用了临时表|对主从数据一致性要求不太高，可能会用到函数、存储过程、触发器等场景|优缺点介于statement和row模式之间
9. 重做日志和二进制日志的区别（至少三点）
-
涉及存储引擎不一样：
binlog记录的是所有存储引擎的操作记录
redo log只记录innodb存储引擎的日志
-
记录内容不一样：
binlog记录的是关于一个事务的具体操作内容。为逻辑日志
而redo log记录的是每个页更改的物理情况
-
写的时间不一样：
binlog文件仅在事务提交前进行提交，即只写磁盘一次
而在事务进行过程中，却不断有重做日志条目被写入到重做日志文件中。
10. Explain执行计划中要关注哪些要素？
- type:本次查询表联接类型，从这里可以看到本次查询大概的效率
- key:最终选择的索引，如果没有索引的话，本次查询效率通常很差
- key_len:本次查询用于结果过滤的索引实际长度
- rows:预计需要扫描的记录数，预计需要扫描的记录数越小越好
- extra:额外附加信息，主要确认是否出现 Using filesort、Using temporary 类似情况