官方文档说明 : https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html
个人推荐：
支付业务:
sync_binlog=1
innodb_flush_log_at_trx_commit=1
其他业务(不考虑主从同步):
sync_binlog=0
innodb_flush_log_at_trx_commit=2
mysql日志操作步骤： log_buff ---mysql写 (write)---> log_file ---OS刷新 (flush)---> disk
# innodb_flush_log_at_trx_commit = 1或者0或者2 参数解释
1（实时写，实时刷）： log_buff —实时—> log_file —实时—> disk
0（延迟写）： log_buff --每隔1秒--> log_file —实时—> disk
2（实时写，延迟刷）： log_buff —实时—> log_file --每隔1秒(还要看OS的调度,大概1秒)--> disk
# 根据容忍丢失数据的多少来选择是 1 还是 2 (非支付业务可以选2或0)
当设置为0 该模式速度最快，但不太安全，mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。
当设置为1 该模式是最安全的，但也是最慢的一种方式。在mysqld 服务崩溃或者服务器主机crash的情况下，
binary log 只有可能丢失最多一个语句或者一个事务。。
当设置为2 该模式速度较快，也比0安全，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。
0 -- 每隔一秒，把事务日志缓存区的数据写到日志文件中，以及把日志文件的数据刷新到磁盘上,
log buffer会每秒写入到日志文件并刷写（flush）到磁盘。但每次事务提交不会有任何影响，
也就是 log buffer 的刷写操作和事务提交操作没有关系。在这种情况下，MySQL性能最好，
但如果 mysqld 进程崩溃，通常会导致最后 1s 的日志丢失
1 -- 每个事务提交时候，把事务日志从缓存区写到日志文件中，并且刷新日志文件的数据到磁盘上,
当取值为 1 时，每次事务提交时，log buffer 会被写入到日志文件并刷写到磁盘。
这也是默认值。这是最安全的配置，但由于每次事务都需要进行磁盘I/O，所以也最慢
2 -- 每事务提交的时候，把事务日志数据从缓存区写到日志文件中；每隔一秒，刷新一次日志文件，但不一定刷新到磁盘上，
而是取决于操作系统的调度,当取值为 2 时，每次事务提交会写入日志文件，但并不会立即刷写到磁盘，日志文件会每秒刷写一次到磁盘。
这时如果 mysqld 进程崩溃，由于日志已经写入到系统缓存，所以并不会丢失数据，
在操作系统崩溃的情况下，通常会导致最后 1s 的日志丢失
sync_binlog 控制MySQL服务器将二进制日志同步到磁盘的频率
# 官方文档
sync_binlog=0：禁用MySQL服务器将二进制日志同步到磁盘。相反，MySQL服务器依赖于操作系统来不时地将二进制日志刷新到磁盘，就像对任何其他文件一样。
此设置提供最佳性能，但在电源故障或操作系统崩溃的情况下，服务器可能已提交尚未同步到二进制日志的事务。
sync_binlog=1：在提交事务之前，允许将二进制日志同步到磁盘。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。
如果发生电源故障或操作系统崩溃，二进制日志中缺少的事务仅处于准备状态。这允许自动恢复例程回滚事务，这保证了二进制日志中没有丢失任何事务。
sync_binlog=N，其中N是0或1以外的值：N在收集二进制日志提交组后，二进制日志将同步到磁盘 。如果发生电源故障或操作系统崩溃，服务器可能已提交尚未刷新到二进制日志的事务。
由于磁盘写入次数增加，此设置可能会对性能产生负面影响。较高的值可提高性能，但会增加数据丢失的风险。
为了在InnoDB与事务一起使用的复制设置中尽可能具有持久性和一致性，请使用以下设置(性能最差,支付业务考虑)：
sync_binlog=1
innodb_flush_log_at_trx_commit=1
