正文
a. binlog cache--->binlog 文件
通过参数 sync_binlog 控制
这个参数是对于 MySQL 系统来说是至关重要的，他不仅影响到 Binlog 对 MySQL 所带来的性能损耗，而且还影响到 MySQL 中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：
●
sync_binlog=0，
当事务提交之后，MySQL 不做 fsync 之类的磁盘同步指令刷新 binlog_cache 中的信息到磁盘，而让 Filesystem 自行决定什么时候来做同步，或者 cache 满了之后才同步到磁盘。
●
sync_binlog=n，
当每进行 n 次事务提交之后，MySQL 将进行一次 fsync 之类的磁盘同步指令来将 binlog_cache 中的数据强制写入磁盘。
在 MySQL 中系统默认的设置是 sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统 Crash，在 binlog_cache 中的所有 binlog 信息都会被丢失。
而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为 1 的时候，即使系统 Crash，也最多丢失 binlog_cache 中未完成的一个事务，对实际数据没有任何实质性影响。
从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为 0 和设置为 1 的系统写入性能差距可能高达5倍甚至更多。
b. redo log buffer--->redo log
通过参数 innodb_flush_log_at_trx_commit 控制
有三个参数值：
0：
log buffer 将每秒一次地写入 log file 中，并且 log file 的 flush (刷到磁盘) 操作同时进行。该模式下在事务提交的时候，不会主动触发写入磁盘的操作。
1：
每次事务提交时 mysql 都会把 log buffer 的数据写入 log file，并且 flush (刷到磁盘) 中去，该模式为系统默认。
2：
每次事务提交时 mysql 都会把 log buffer 的数据写入 log file，但是 flush (刷到磁盘) 操作并不会同时进行。该模式下，MySQL 会每秒执行一次 flush (刷到磁盘) 操作
c. 脏页 data_buffer---->数据文件
1. 通过参数 innodb_max_dirty_pages_pct 控制：它的含义代表脏页刷新占 buffer_pool 的比例；个人建议调整为 25-50%；
2. 日志切换会产生检查点 checkpoint，可以诱发对脏页的刷新
——线程工作：
Innodb 四大 IO 线程：
write thread，read thread，insert buffer thread，redo log thread
master thread 是数据库的主线程，优先级别最高，里面包含 1s 和 10s 对数据库的操作。
page cleaner thread：帮助刷新脏页的线程，5.7 版本可以增加多个。
purge thread ：删除无用 undo 页。默认1个，最大可以调整到 32。
主要的数据文件也是我们需要学习：
参数文件：MySQL 5.6 版本 my.cnf 和 MySQL 5.7 版本的 my.cnf
这里给大家两个模板：
老张根据生产环境上测试而出的参数。其中根据真实内存去适当调整 innodb_buffer_pool 大小就可以了。（建议物理内存的50-80%）
MySQL 5.7 版本的参数文件：
——日志文件：
1. 错误日志 error log：
对 mysql 启动，运行，关闭过程进行了记录。
2. 全量日志 general log：
查询日志记录了所有对 mysql 数据库请求的信息，不论这些请求是否得到了正确的执行。
3. 二进制日志 binlog：
记录了对数据库执行更改的所有操作。但是并不包括 select 和 show 这类操作。
4. 中继日志 relay log：
主从同步，从库需要把主库传递过来的日志，记录到自己的 relay log 里面。
5. 慢查询日志 slow log：
运行时间超过某值的所有 sql 语句都记录到慢查询日志文件中。
