问题，项目后台有一个定时任务，需要跑一批数据，跑完后存入到一个表里，用来做信息查询，数据大，逻辑复杂，耗时，多线程处理数据？
解答：以为程序的问题，把所有的关键点步骤都加上了日志，拿开发环境的日志看，一点没毛病，后来排查到Mysql，是不是服务器挂了，通过命令来查看，确实没有挂，是不是项目过载，也挂了，也没有，最后想起来，mysql可能不是实时刷入磁盘的，所有像运维拿到了my.cnf配置文件，果然是一个参数问题。运维让插入数据度快，innodb_flush_log_at_trx_commit 这个参数设置了2，后来查阅了资料，看到这些代表的意义。
innodb引擎。
设置一个参数 innodb_flush_log_at_trx_commit = 2 插入速度立马变快，提升了数十倍。 这个参数有什么意义？ 该参数取值可以是0,1,2
innodb_flush_log_at_trx_commit = 0，Innodb 中的Log Thread 没隔1 秒钟会将log buffer中的数据写入到文件，同时还会通知文件系统进行文件同步的flush 操作，保证数据确实已经写入到磁盘上面的物理文件。但是，每次事务的结束（commit 或者是rollback）并不会触发Log Thread 将log buffer 中的数据写入文件。所以，当设置为0 的时候，当MySQL Crash 和OS Crash 或者主机断电之后，最极端的情况是丢失1 秒时间的数据变更。
innodb_flush_log_at_trx_commit = 1，这也是Innodb 的默认设置。我们每次事务的结束都会触发Log Thread 将log buffer 中的数据写入文件并通知文件系统同步文件。这个设置是最安全的设置，能够保证不论是MySQL Crash 还是OS Crash 或者是主机断电都不会丢失任何已经提交的数据。
innodb_flush_log_at_trx_commit = 2，当我们设置为2 的时候，Log Thread 会在我们每次事务结束的时候将数据写入事务日志，但是这里的写入仅仅是调用了文件系统的文件写入操作。而我们的文件系统都是有缓存机制的，所以Log Thread 的这个写入并不能保证内容真的已经写入到物理磁盘上面完成持久化的动作。文件系统什么时候会将缓存中的这个数据同步到物理磁盘文件Log Thread 就完全不知道了。所以，当设置为2 的时候，MySQL Crash 并不会造成数据的丢失，但是OS Crash 或者是主机断电后可能丢失的数据量就完全控制在文件系统上了。
