{"id":3575,"date":"2026-04-04T17:01:09","date_gmt":"2026-04-04T17:01:09","guid":{"rendered":"https:\/\/kedar.nitty-witty.com\/blog\/?p=3575"},"modified":"2026-04-04T17:01:09","modified_gmt":"2026-04-04T17:01:09","slug":"how-to-fix-write-latency-in-mysql-8-4-upgrade","status":"publish","type":"post","link":"https:\/\/kedar.nitty-witty.com\/blog\/how-to-fix-write-latency-in-mysql-8-4-upgrade","title":{"rendered":"How to fix write latency in MySQL 8.4 Upgrade"},"content":{"rendered":"\n

During any MySQL major version upgrade<\/strong>, especially when moving from 8.0 to 8.4, it\u2019s not just about compatibility checks. Subtle default changes can directly impact MySQL performance tuning<\/strong>, and if you\u2019re not watching closely, they can show up as unexpected latency or throughput issues.<\/p>\n\n\n\n

This is a tale from a MySQL 8.4 upgrade causing write latency and the default change of innodb_change_buffering<\/code>. <\/p>\n\n\n\n

InnoDB\u2019s change buffer (innodb_change_buffering<\/code>) used to be an important optimisation for write-heavy workloads. However, in MySQL 8.4, it is disabled by default<\/strong>. Remember, it is disabled<\/em>, not deprecated<\/strong> (at least as of now).<\/p>\n\n\n\n

This blog post walks through a small but practical use case and what it means for real-world systems.<\/p>\n\n\n\n

\n\n\n\n

What the change buffer was for<\/h1>\n\n\n\n

InnoDB\u2019s change buffer (formerly insert buffer) was designed for secondary indexes when the required leaf page is not present in the buffer pool.<\/p>\n\n\n\n

Instead of performing a random read to fetch that page just to apply an insert, delete-mark, or purge operation, InnoDB records the change in the change buffer and merges it later.<\/p>\n\n\n\n

On spinning disks, where random seeks were expensive and sequential I\/O was cheaper, this provided a real performance benefit and played a role in MySQL write optimization<\/strong>. I have it covered in my previous blog \/ podcast below.<\/p>\n\n\n\n

Reference: https:\/\/kedar.nitty-witty.com\/blog\/mysql-change-buffer-what-when-and-faq<\/a>
Podcast: https:\/\/www.youtube.com\/watch?v=vt78zI_fwfU<\/a><\/p>\n\n\n\n\n\n

\n\n\n\n

Why is innodb_change_buffering<\/code> off by default?<\/h1>\n\n\n\n

1. Database hardware has changed<\/h2>\n\n\n\n

On most modern systems, storage is SSD\/NVMe or RAID-backed, where random I\/O is significantly faster compared to traditional HDDs.<\/p>\n\n\n\n

The original benefit of change buffering was to avoid slow random disk reads for secondary index updates. That bottleneck largely no longer exists.<\/p>\n\n\n\n

So effectively:<\/p>\n\n\n\n

\n

If random I\/O is no longer expensive, avoiding it brings less value for most MySQL workloads<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

2. Additional overhead<\/h2>\n\n\n\n

Maintaining the change buffer is not free.
– Extra writes
– Additional metadata tracking
– Background merge operations<\/p>\n\n\n\n

All of this adds overhead to write operations and can impact MySQL query performance<\/strong>, especially under sustained write load.<\/p>\n\n\n\n

So question arise:<\/p>\n\n\n\n

\n

Does the optimisation still justify the cost?<\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

In my understanding, this is not a case of \u201cChange buffer is useless<\/strong>\u201d but rather \u201cChange buffer is not beneficial enough<\/strong>\u201d<\/p>\n\n\n\n

\n\n\n\n

This aligns with MySQL 8.4 LTS philosophy of more practical defaults for MySQL performance optimization<\/strong>:<\/p>\n\n\n\n

innodb_change_buffering: all \u2192 none<\/pre>\n\n\n\n
Effectively disabling it out of the box.But why disable it and not remove it? I can\u2019t speak on behalf of MySQL, but I\u2019m actually glad it\u2019s still there.<\/p>\n\n\n\n
8.4 Upgrade and Write Latency<\/h2>\n\n\n\n
A “friend” of mine upgraded from MySQL 8.0 to 8.4 and quickly hit the panic button, as their write latency<\/strong> almost doubled. From ~2ms to ~4ms. Now, I may joke about it saying “dude, that’s just 2ms” but for latency-sensitive systems, that\u2019s significant for database performance<\/strong>.<\/p>\n\n\n\n
I know, you being a smart reader would have doubted innodb_change_buffering behaviour and so did I.<\/p>\n\n\n\n
We reverted:<\/p>\n\n\n\n
innodb_change_buffering = all<\/pre>\n\n\n\n
\u2026and the latency dropped back to expected levels. <\/p>\n\n\n\n
You probably already know this, and maybe I did bait you a bit with the \u201chow to fix\u201d title. But in reality, I just wanted to put this out there for someone who might find it useful.<\/strong><\/em><\/p>\n\n\n\n
\n\n\n\n
Will the change buffering stay?<\/h1>\n\n\n\n
We don\u2019t really know.<\/p>\n\n\n\n
Maybe it will stay, maybe it won\u2019t. Defaults have already shifted, and future versions may evolve further as MySQL continues to refine… but this brings us to the important takeaway:<\/p>\n\n\n\n
\n
Always test every aspect of your workload during a MySQL upgrade<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n
Especially when even a few milliseconds of latency change can have real impact on MySQL performance tuning and query optimization<\/strong>.<\/p>\n\n\n\n
\n\n\n\n
Final note<\/h1>\n\n\n\n
I recently covered a MySQL Major Version Upgrade Checklist<\/strong> in a podcast, focused on practical upgrade strategies, validation steps, and avoiding surprises like this one.<\/p>\n\n\n\n
If you\u2019re planning an upgrade, it might be a useful reference.<\/p>\n\n\n\n
\n