我们知道，MySQL为了保证数据的尽量不丢失，一般会把参数sync_binlog 和innodb_flush_log_at_trx_commit都设置为1，即双1原则，但是，凡是都有两面性，高安全和高性能往往是让人很难取舍的，需要根据你的实际业务需求进行抉择；
1.测试背景
首先分别了解一下这两个参数的官方解释:
sync_binlog
Controls how often the MySQL server synchronizes the binary log to disk. 控制MySQL server 同步binlog到磁盘的频率 sync_binlog=0: Disables synchronization of the binary log to disk by the MySQL server. Instead, the MySQL server relies on the operating system to flush the binary log to disk from time to time as it does for any other file. This setting provides the best performance, but in the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been synchronized to the binary log. 关闭MySQL server binlog同步到磁盘，由OS不时的刷新到磁盘，这是MySQL最好的性能，但是当断电或者系统崩溃，MySQL server已经提交的事物可能还没有同步到binlog，导致事物丢失。 sync_binlog=1: Enables synchronization of the binary log to disk before transactions are committed. This is the safest setting but can have a negative impact on performance due to the increased number of disk writes. In the event of a power failure or operating system crash, transactions that are missing from the binary log are only in a prepared state. This permits the automatic recovery routine to roll back the transactions, which guarantees that no transaction is lost from the binary log. 在事物提交之前同步binlog到磁盘，这是最安全的，但是由于增加了磁盘的写操作，会有一些消极的性能影响。当断电或者系统崩溃，从binlog中丢失的事物仅仅处于准备状态。这个允许自动恢复程序去rollback事物，保证binlog没有事物丢失。 sync_binlog=N, where N is a value other than 0 or 1: The binary log is synchronized to disk after N binary log commit groups have been collected. In the event of a power failure or operating system crash, it is possible that the server has committed transactions that have not been flushed to the binary log. This setting can have a negative impact on performance due to the increased number of disk writes. A higher value improves performance, but with an increased risk of data loss. 在N个binlog提交组被收集到之后，binglog同步到磁盘。当断电或者系统崩溃，已经提交的事物可能还没有刷新到binlog。这样的配置增加了磁盘的写操作，会有一些消极的性能影响。N值越高，数据库性能越好，但是数据越可能丢失。 For the greatest possible durability and consistency in a replication setup that uses InnoDB with transactions, use these settings: 为了使使用InnoDB的复制设置具有最大的持久性和一致性，请使用以下设置: sync_binlog=1. innodb_flush_log_at_trx_commit=1. Caution Many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken place, even though it has not. In this case, the durability of transactions is not guaranteed even with the recommended settings, and in the worst case, a power outage can corrupt InnoDB data. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can also try to disable the caching of disk writes in hardware caches. 许多操作系统和一些磁盘硬件欺骗了刷新磁盘的操作。它们可能会告诉sqmyld flush已经发生了，尽管没有发生。在这种情况下，即使使用推荐的设置，事务的持久性也不能得到保证，在最坏的情况下，断电可能损坏InnoDB数据。在SCSI磁盘控制器或磁盘本身中使用电池支持的磁盘缓存可以加速文件刷新，并使操作更加安全。您还可以尝试禁用硬件缓存中的磁盘写缓存。
innodb_flush_log_at_trx_commit
Controls the balance between strict ACID compliance for commit operations and higher performance that is possible when commit-related I/O operations are rearranged and done in batches. You can achieve better performance by changing the default value but then you can lose up to a second of transactions in a crash. 控制提交操作严格遵守ACID和提高性能之间的平衡，这在批量重新安排和执行与提交相关的I/O操作时是可能的，通过更改默认值，您可以获得更好的性能，但是在崩溃时，你可能会损失多达一秒钟的事务 The default value of 1 is required for full ACID compliance. With this value, the contents of the InnoDB log buffer are written out to the log file at each transaction commit and the log file is flushed to disk. 默认值1是必须的对ACID性.InnoDB日志缓冲区的内容在每个事务提交时被写到日志文件，日志文件被刷新到磁盘。 With a value of 0, the contents of the InnoDB log buffer are written to the log file approximately once per second and the log file is flushed to disk. No writes from the log buffer to the log file are performed at transaction commit. Once-per-second flushing is not guaranteed to happen every second due to process scheduling issues. Because the flush to disk operation only occurs approximately once per second, you can lose up to a second of transactions with any mysqld process crash. 值为0时，InnoDB日志缓冲区的内容大约每秒写入一次日志文件，日志文件被刷新到磁盘。事务提交时不执行从日志缓冲区写入日志文件的操作。由于进程调度问题，不能保证每秒一次刷新。由于对磁盘的刷新操作大约每秒钟只发生一次，因此您可以在任何mysqld进程中损失最多一秒钟的事务 With a value of 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and the log file is flushed to disk approximately once per second. Once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues. Because the flush to disk operation only occurs approximately once per second, you can lose up to a second of transactions in an operating system crash or a power outage. 当值为2时，InnoDB日志缓冲区的内容在每次事务提交后被写入日志文件，日志文件大约每秒被刷新一次。由于进程调度问题，每秒一次的刷新不能100%保证每秒发生。由于磁盘刷新操作大约每秒发生一次，所以在操作系统崩溃或断电时，最多可能损失1秒的事务。 InnoDB log flushing frequency is controlled by innodb_flush_log_at_timeout, which allows you to set log flushing frequency to N seconds (where N is 1 ... 2700, with a default value of 1). However, any mysqld process crash can erase up to N seconds of transactions. DDL changes and other internal InnoDB activities flush the InnoDB log independent of the innodb_flush_log_at_trx_commit setting. InnoDB crash recovery works regardless of the innodb_flush_log_at_trx_commit setting. Transactions are either applied entirely or erased entirely. For durability and consistency in a replication setup that uses InnoDB with transactions: If binary logging is enabled, set sync_binlog=1. Always set innodb_flush_log_at_trx_commit=1. Caution Many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken place, even though it has not. In this case, the durability of transactions is not guaranteed even with the recommended settings, and in the worst case, a power outage can corrupt InnoDB data. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can also try to disable the caching of disk writes in hardware caches.
2.测试配置
这里TPCC和MySQL分别在两台机器上面，是为了排除TPCC运行过程中对MySQL服务资源的占用的影响
IP:172.16.101.54
CPU:2core
Memory:8G
软件:tpcc-mysql-master
IP:172.16.101.55
CPU:2core
Memory:6G
软件:MySQL5.7.21
MySQL其他部分参数配置:
key_buffer_size = 8M sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 4M query_cache_size= 0M query_cache_type= off max_allowed_packet = 64M myisam_sort_buffer_size=128M tmp_table_size=32M table_open_cache = 2000 thread_cache_size = 8 wait_timeout = 300 interactive_timeout = 300 max_connections = 8000 max_user_connections=0 innodb_thread_concurrency = 4 transaction_isolation = READ-COMMITTED gtid-mode = on enforce-gtid-consistency = true log_slave_updates = on innodb_buffer_pool_size = 5120M innodb_log_buffer_size = 16M innodb_lock_wait_timeout = 100
3.测试过程
测试主要分两种情况，通过tpcc测得MySQL server的tps和qps，每一种情况测试三遍，取平均值，并做成表格和折线图。
innodb_flush_log_at_trx_commit = 1 && sync_binlog = 1
or
innodb_flush_log_at_trx_commit = 0 && sync_binlog = 0
4.测试结果
首先说明一下，因为手头上只有这样低配置的服务器，所以测试结果不是那么的可靠，所以仅仅参考测试思想和过程即可，不要太在意测试结果，哈哈。
（1）TpmC
即每分钟的事物数
| 线程数 | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1024 | 1536 | 2048 |
| i=1&s=1 | 864.433 | 1411.367 | 2020.667 | 2465.867 | 2666.533 | 2666.633 | 2614.333 | 2431.267 | 2011.233 | 1507.733 | 1266.1 |
| i=0&s=0 | 2761.383 | 3160.05 | 2835.817 | 2510.683 | 2366.017 | 2303.25 | 2367.517 | 2251.817 | 1834.583 | 1439.684 | 1166.3 |
从图中我们可以看到：
并发0-32的时候，双0的MySQL TpmC远远大于双1;
并发>32后，两者之间的TpmC数量差不多
（2）双1情况下的 slow queries，open tables，Queries per second avg等指标的情况
从图中我们可以看到：
随着并发越来越大，slow queries也越来越多；
当并发达到512左右，open tables也达到参数table_open_cache = 2000的设定值；
随着并发越来越大，QPS越来越小，刚开始并不明显，一度处于平衡，知道并发太大，QPS性能下降；
参考链接：
《MySQL压测--TPCC安装，测试》 http://blog.51cto.com/darrenmemos/2130202
《MySQL压测--注意事项和FAQ》 http://blog.51cto.com/darrenmemos/2132084