由于是并发乱序写log_buffer，那么无法保证按lsn递增有序加入到flush_list，也就无法推进检查点。MySQL 8.0通过限制大于一定阀值L的lsn加入到flush_list做为权衡，假设当前flush_list的lsn最大值为M，那么只有在M值与当前线程lsn相差范围在L以内时，才将脏页写入flush_list。同样的，推进M，也依赖于link_buf变量recent_closed。这种策略本质上放宽了之前对于flush_list中对于LSN全局有序的限制到L范围内的有序。
除了日志系统变成lock free，MySQL8.0还将写日志线程从用户线程中拆分出来，有单独的log writer线程和log flusher后台线程来处理写日志和sync日志。原来的写日志方式是，大家随机group-commit，由一个线程负责write/flush日志，其它线程等待，这种模式下group的大小比较随机。拆分后，处理更灵活，batch大小也更好控制，而且对于flush_log_at_trx_commit!=1的场景，只需要等log writer的通知即可。
总结
从MySQL日志系统优化的演进过程来看，始终是围绕锁log_sys_t::mutex展开。 从最初的按功能拆分出log_sys_t::flush_order_mutex，到按读写拆分实现为双log_buffer，以及最新的MySQL 8.0利用无锁机制彻底去掉这把锁，显然MySQL的并发能力是越来越强的。这种优化“套路”其实是比较朴素通用的，对于一个新的系统，通过一把大锁能简化并发逻辑，优先保证正确性。在系统慢慢演进过程中，我们可以按功能拆分锁，缓解锁冲突压力；如果某把锁处于核心链路，而且又成为瓶颈，那么再想办法继续拆，或者实现为无锁，彻底解决并发冲突问题，目的只有一个就是充分利用多核CPU资源，然线程多干活，减少响应时间的同时，拉高吞吐量，而不是都等待空闲着。文章中并没有涉及更多关于MySQL8.0日志系统优化的细节，官方文档已经写的足够好，大家可以详细看看。
Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx