MySQL中的IO流

来源：这里教程网时间：2026-03-01 16:49:47 作者：

MySQL中的I/任务很多，比如从buffer pool flush 脏页去磁盘，或者是merge change buffer中的内容到二级索引，InnoDB也一直在做着IO相关的优化工作，今天从IO参数入手，去学习IO相关的内容吧!IO相关

1.Configuring InnoDB I/O Capacity

1.1 innodb_io_capacity

默认值200，最小100，最大2的64次方-1，是所有buffer_pool_instance的设置，当flush发生的时候，capacity被平均到每个instance上。defines the number of I/O operations per second (IOPS) available to InnoDB background tasks，这个参数设置的话，一些后台任务的调整可能会依据你设置的值来作为参考了。设置太高也不好，会让buffer pool的效果更差。设置太低，则影响性能，主要还是看自己的磁盘性能，设置一个合理的值，一般超过2w就不推荐了。

1.2 innodb_flush_sync

默认开启，这个参数在checkpoint时如果有大量的IO发生是会忽略掉innodb_io_capacity的设置的，注意这点。

1.3 innodb_io_capacity_max

如果没有设置innodb_io_capacity_max那么它的值初始化的时候会被定义为 max(innodb_io_capacity *2 ,2000)

2.Configuring Buffer Pool Flushing

2.1 innodb_page_cleaners

默认为4，如果设置的值超过了buffer pool instance的个数，则自动设置为和buffer pool instance 相同数值。

2.2 innodb_max_dirty_pages_pct_lwm

The default low water mark is 10% of buffer pool pages. A innodb_max_dirty_pages_pct_lwm value of 0 disables this early flushing behaviour.

2.3 innodb_max_dirty_pages_pct

脏页最大比例，默认90%

2.4 innodb_flush_neighbors

0 表示不刷相同区内的邻近脏页，1表示刷相同区的邻近脏页，2表示刷相同区的所有脏页。

2.5 innodb_lru_scan_depth

how far down the buffer pool LRU list the page cleaner thread scans looking for dirty pages to flush.如果是写密集型应用且IO接近饱和，那么应该减小这个值。一般挑战了buffer pool大小之后都建议调整这个值，innodb_lru_scan_depth * innodb_buffer_pool_instances决定page cleaning线程每秒的工作量。

2.6 innodb_adaptive_flushing_lwm

这个值定义了redo log容量的低水位，当超过这个值adaptive flushing就会开启，即使 innodb_adaptive_flushing是关闭的。

2.7 innodb_adaptive_flushing

adaptive flushing算法默认开启，主要为了保证redo log不会满。

2.8 innodb_flushing_avg_loops

默认30，1-1000，Number of iterations for which InnoDB keeps the previously calculated snapshot of the flushing state, controlling how quickly adaptive flushing responds to changing workloads.根据之前flush状态的计算快照来进行的迭代次数，调高则频率调整的更平滑，调低则频率调整的更激进。如果redo log文件空间较大，很少有尖刺会到达75%的容量，那么可以增加这个值，让调整更加平滑。

2.9 innodb_idle_flush_pct

8.0.18之后可以定义这个值，它是innodb_io_capacity的比值，默认是100%，限制空闲时间刷buffer pool的比例，设置这个比例小于100%可以延长SSD寿命，但是也有副作用，限制空闲时间刷脏页的比例会导致一个长时间空闲之后的crash的恢复时间较长以及一个较长时间的shutdown。

3.Purge Configuration

purge 什么叫purge呢?就是删除数据不会立马被删除而是被打上标记，等后面MVCC不需要对应的undo的时候，这个记录就可以被物理删除了，这个过程叫purge。

3.1innodb_purge_threads

默认为4.最大32，当DML发生的表比较少，则这个值不要设置太大，会产生冲突;DML并发操作的表比较多，那么可以调大这个值。这个值只是一个最大值，系统会自动调整。

3.2 innodb_max_purge_lag

默认为0，8.0.26引入。如果DML操作单张表，那么只有一个thread会进行purge操作，导致purge比较慢，产生purge lag，并且如果事务涉及到的行比较多的话，还会增加表空间大小，这个时候如果超过了lag的大小，那么purge任务则会被自动的分布到可用的thread上，过多的活跃清理线程会和用户线程产生冲突，所以要根据实际情况进行这个参数的调整。

3.3 innodb_purge_batch_size

定义了每批处理history list中undo 页面的个数，默认是300.平均分到每个线程上进行处理。清理线程也会清理不需要的undo log 页面，128次迭代之后会进行清理，这个值也会定义每次清理的undo 页面数量。

3.4 innodb_max_purge_lag

默认是0，当这个lag到达阈值，DML操作将会延迟，直到lag被追上。innodb事务维护了一张有标记为删除的索引记录列表，这张表的长度就是purge lag，在8.0.14之前，purge lag的延迟是通过(purge lag/innodb_max_purge_lag - 0.5) * 10000这个公式计算的，这会导致最少5000微妙的延迟，8.014的之后通过(purge_lag/innodb_max_purge_lag - 0.9995) * 10000来计算，这样最小延迟5微秒。