1. 日志
1.1 错误日志
记录数据库在启动、运行及停止过程中的各种错误信息。默认开启，存放位置在/var/log，默认文件名是mysqld.log。查看日志位置：show variables like '%log_error%';
1.2 二进制日志※※
记录所有DDL和DML语句。作用：①. 灾难时的数据恢复；②. MySQL的主从复制。 在MySQL8版本中，默认开启的，查看日志位置show variables like '%log_bin%';。包含两个部分，索引文件和log文件（编号从000001开始）。
1.2.1 格式
- STATEMENT：记录的是SQL语句
- ROW：记录的是每一行的数据变更。（默认）
- MIXED：混合了STATEMENT和ROW两种格式，默认采用STATEMENT，在某些特殊情况下会自动切换为ROW进行记录。
可以进行自行配置二进制日志格式。
1.2.2 删除
可以通过两种方式删除日志，一、定时，二、手动删除
1.2.3 查询日志
查询日志中记录了客户端的所有增删改查操作语句，而二进制日志不包含查询数据的SQL语句。默认未开启。
1.2.4 慢查询日志※※
记录所有超过设置的时间并且不小于最小扫描行数的所有SQL语句，默认未开启，默认超时时间为10秒，
可以通过/etc/my.cnf文件配置：
#慢查询日志
slow_query_log=1
#执行时间参数
long_query_time=2
默认不记录管理语句和不使用索引的查找语句
#记录执行较慢的管理语句
log_slow_admin_statements =1
#记录执行较慢的未使用索引的语句
log_queries_not_using_indexes = 1
2. 主从复制※※※※※
是指主库将二进制日志文件发送到从库，对日志进行重新操作，使从库和主库保持数据同步。可以一主多从，从库同时也可以作为其他从服务器的主库，实现链状复制。
2.1 作用
- 失败迁移。主库出现问题，可以快速切换到从库提供服务。
- 读写分离。降低主库的访问压力。
- 数据备份。可以在从库中执行备份，以避免备份期间影响主库服务。
2.2 实现原理
- Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
- 从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。从库IO线程提供该功能。
- slave重做中继日志中的事件，将改变反映它自己的数据。从库SQL线程提供该功能
所以从库为了实现主从复制，将启动两个线程，一个IO线程读取主库的二进制日志文件并写入中间日志文件，一个SQL线程执行中间日志文件写入自身数据库。
3. 分库分表
3.1 出现原因
单一数据库有以下问题：
- IO瓶颈：热点数据太多，数据库缓存不足，产生大量磁盘IO，效率较低。 请求数据太多，带宽不够，网络IO瓶颈。
- CPU瓶颈：排序、分组、连接查询、聚合统计等SQL会耗费大量的CPU资源，请求数太多，CPU出现瓶颈。
为了解决上述问题，出现分库分表解决方案。
3.2 拆分策略
有两种形式，垂直拆分和水平拆分，两种粒度，分库和分表，可以两两组合，对于分库后还是出现严重瓶颈的（热点数据导致），可以将热点数据进行分表。
- 垂直拆分
- 垂直分库：对当前数据库以表为单位按照进行分库，表数据不拆分
- 垂直分表：对当前数据库以表中字段为单位按照一定的规则进行分表，表结构不一致，一般以主键或者外键为关联
- 水平拆分
- 水平分库：对当前数据库进行分库，每个数据库都保存表的一部分，表结构一致，数据不一致
- 水平分表：对表中数据再次水平拆分，表结构一致，数据不一致
具体用哪种看业务需求，一般垂直分库，水平分表。
3.3 实现技术
- shardingJDBC：基于AOP原理，在应用程序中对本地执行的SQL进行拦截，解析、改写、路由处理。需要自行编码配置实现，只支持java语言，性能较高。
- MyCat：数据库分库分表中间件，不用调整代码即可实现分库分表，支持多种语言，性能不及前者。
- MyCat实现原理：MyCat会先将SQL进行解析，看需要的数据在哪些分库中，从这些分库中取出数据并且整合结果，之后进行聚合、排序、分页处理
4. 读写分离※※※※※
为了减轻主库的压力，会将读写功能拆分，主库写，从库读，客户端直接操作读写分离会导致代码比较复杂，所以一般通过中间件来实现分离操作。
为了防止主库宕机产生问题，一般使用双主双从架构模式，即两台主机两台从机，一个主机 Master1 用于处理所有写请求，它的从机 Slave1 和另一台主机 Master2 还有它的从机 Slave2 负责所有读请求。当 Master1 主机宕机后，Master2 主机负责写请求，Master1 、Master2 互为备机。
