InnoDB Buffer Pool Configuration aggressively flushes buffer pool pages if the percentage of dirty pages in the buffer pool reaches the innodb_max_dirty_pages_pct  threshold. When configuring  innodb_max_dirty_pages_pct_lwm , the value should always be lower than the innodb_max_dirty_pages_pct  value. Additional variables permit fine-tuning of buffer pool flushing behavior: •The  innodb_flush_neighbors  variable defines whether flushing a page from the buffer pool also flushes other dirty pages in the same extent. •The default setting of 0 disables  innodb_flush_neighbors . Dirty pages in the same extent are not flushed. This setting is recommended for non-rotational storage (SSD) devices where seek time is not a significant factor. •A setting of 1 flushes contiguous dirty pages in the same extent. •A setting of 2 flushes dirty pages in the same extent. •The  innodb_lru_scan_depth  variable specifies, per buffer pool instance, how far down the buffer pool LRU list the page cleaner thread scans looking for dirty pages to flush. This is a background operation performed by a page cleaner thread once per second. When table data is stored on a traditional HDD storage device, flushing neighbor pages in one operation reduces I/O overhead (primarily for disk seek operations) compared to flushing individual pages at different times. For table data stored on SSD, seek time is not a significant factor and you can disable this setting to spread out write operations. A setting smaller than the default is generally suitable for most workloads. A value that is significantly higher than necessary may impact performance. Only consider increasing the value if you have spare I/O capacity under a typical workload. Conversely, if a write-intensive workload saturates your I/O capacity, decrease the value, especially in the case of a large buffer pool. When tuning  innodb_lru_scan_depth , start with a low value and configure the setting upward with the goal of rarely seeing zero free pages. Also, consider adjusting  innodb_lru_scan_depth when changing the number of buffer pool instances, since  innodb_lru_scan_depth  * innodb_buffer_pool_instances  defines the amount of work performed by the page cleaner thread each second. The  innodb_flush_neighbors  and  innodb_lru_scan_depth  variables are primarily intended for write-intensive workloads. With heavy DML activity, flushing can fall behind if it is not aggressive enough, or disk writes can saturate I/O capacity if flushing is too aggressive. The ideal settings depend on your workload, data access patterns, and storage configuration (for example, whether data is stored on HDD or SSD devices). InnoDB  uses an adaptive flushing algorithm to dynamically adjust the rate of flushing based on the speed of redo log generation and the current rate of flushing. The intent is to smooth overall performance by ensuring that flushing activity keeps pace with the current workload. Automatically adjusting the flushing rate helps avoid sudden dips in throughput that can occur when bursts of I/O activity due to buffer pool flushing affects the I/O capacity available for ordinary read and write activity. Sharp checkpoints, which are typically associated with write-intensive workloads that generate a lot of redo entries, can cause a sudden change in throughput, for example. A sharp checkpoint occurs when  InnoDB wants to reuse a portion of a log file. Before doing so, all dirty pages with redo entries in that portion of the 3118 Adaptive Flushing