The latest from the MySQL community

I am continuing my blog post series on using indexes — or tables — as queues.  In this post, I cover Row Deletion Jobs (I do not call these purge jobs, to avoid confusion with the InnoDB Purge).  Such jobs are tempting to implement using an index, but this might be a wrong / suboptimal way.  I write about the right / better / cheaper way

I am starting a blog post series on using indexes — or tables — as queues.  I had this series in the back of my mind for some time.  This started a few years back when I worked on optimizing a row deletion job (I do not call this a purge job, to avoid confusion with the InnoDB Purge).  Such jobs can be generalized to using indexes (or tables) as queues (this is

Something changed in MySQL 8.4 related to caching, and it is easy to miss, so it deserves a post.  And a subject adjacent to this is the missing Release Candidate for MySQL 8.4 LTS, with my hope that the next LTS will have a Release Candidate, so I also cover this topic below.

(if you are not interested in Caching and Flushing, you can jump directly to the section about Release Candidate)

There is a special kind of boredom that only database people know. The kind where you stare at a server humming along and think, surely there is something here I can tune. Good news: there is.

This post walks through the most important MySQL variables to tune for performance, why they matter, and when touching them helps versus when it quietly makes things worse. This is written with InnoDB-first workloads in mind, because let’s be honest, that’s almost everyone.

1. innodb_buffer_pool_size Real metrics to watch

Before touching this variable, look at these:

sql Copy Copied!

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Key fields:

• Innodb_buffer_pool_reads – physical reads from disk
• Innodb_buffer_pool_read_requests – logical reads

…

I am upset about this one : I have a hard time not seeing this as negligence, and it starts to become a pattern...  So please forgive me if this post is not my most diplomatic, because I really think someone deserves a kick in the butt !  But what is all this about...

There is a MySQL bug, which can lead to data corruption, opened for 8.0 in September 2023, fixed in MySQL 8.4.0 (

A unique constraint specifies, one or more columns as unique it identifies. It is satisfied only when no two rows store the same non-null values at its core. A primary key constraint is a unique one that will say PRIMARY KEY in its defined way. It is satisfied only when rows unfold, and none may […]

In a recent post, The Quirks of Index Maintenance in Open Source Databases, I compared the IO load generated by open source databases while inserting rows in a table with many secondary indexes. Because of its change buffer, InnoDB was the most efficient solution. However, that’s not the end of the story. Evolution of the […]

When you run a simple write, …it may look simple, but under the hood, MySQL’s InnoDB engine kicks off a pretty complex sequence to ensure your data stays safe, consistent, and crash-recoverable. In the top-left corner of the diagram, we see exactly where this begins — the moment the query is executed: [crayon-697773637c60c399076158/] The log […]

I recently troubleshoot an interesting MySQL crash, and I think it is worth sharing (with the related bugs).  MySQL crashed when the disk was full, you can see the free disk graph below.  The Y-axis is in the tens of GiB scale and the X-axis is in the hour scale.  Can you guess what happened ?

Just to make sure we agree on the meaning of the graph above, let's describe it

In this blog, we continue from where we left off in the previous post, InnoDB Cluster Setup: Building a 3-Node High Availability Architecture, where we demonstrated how to set up a MySQL InnoDB Cluster with three nodes to achieve high availability. Here, we walk through the step-by-step process of performing a rolling upgrade of that […]