The latest from the MySQL community

Posted on MySQL Ninjas | August 2026

Every DBA has been there. An alert fires. You SSH into the box, run free -h, and see MySQL consuming far more RAM than you configured. You double-check innodb_buffer_pool_size. It's set correctly. So where is the memory going?

This is the story of debugging exactly that — on a Google Cloud c4d-standard-4 instance with 14.7 GB RAM, MySQL configured with a 7168 MB buffer pool, and mysqld RSS sitting at 10.4 GB. That's a 3.2 GB gap nobody could explain.

The Setup

We run a large …

Overview

Servers Tested:

• MySQL 9.7.0 (PGO-enabled build released by Oracle)
• MySQL 9.7.0 Non-PGO (built without Profile-Guided Optimization — see BUILD.md)

Tier Configurations:

• Tier 2G: 2GB InnoDB buffer pool
• Tier 12G: 12GB InnoDB buffer pool
• Tier 32G: 32GB InnoDB buffer pool

View Results

Interactive Reports

The benchmark reports are available as interactive HTML pages at:

https://percona-lab-results.github.io/2026-pgo/index.html

Performance …

Introduction

Many MySQL configurations inherit redo log sizing from defaults, aging blog posts, or configuration folklore.

innodb_redo_log_capacity gets set once… and then quietly fades into the background.

But redo log capacity directly shapes how efficiently MySQL absorbs writes, manages checkpoint pressure, and handles burst-heavy workloads.

Set it too low, and aggressive flushing can throttle throughput.
Set it too high, and crash recovery can become painfully long.

Redo logs are more than crash insurance.

They are part of your write-performance architecture.

Redo logs are the shock absorbers of write-heavy MySQL. Too small, and performance jolts. Too large, and recovery drags.

Why Redo Logs Matter

InnoDB redo logs are often described as crash recovery journals, but that description undersells their real operational value.

Redo …

Introduction Replication performance depends on every stage in the pipeline, from the source database to transport and ultimately to commit on the replica. On the replica side, much of that performance comes down to how efficiently changes are read, scheduled, and applied under real operational pressure. In practice, that directly affects steady-state lag, backlog recovery […]

Overview Some MySQL distribution packages, such as the generic Linux build, bundle an OpenSSL dependency within the same .tar.gz archive. With the new MySQL 8.0.46, 8.4.9 and 9.7.0 releases, we are upgrading those bundled packages from using OpenSSL 3.0 to the new OpenSSL 3.5 LTS branch. Native OS packages, such as .rpm and .deb, continue […]

The following report is covering performance evaluation of the currently available OpenSSL releases when they are used by MySQL in CPU-intensive OLTP workloads. However, the main focus is on OpenSSL-3.5.5, which will be used by default in the next MySQL releases.

Read more... (19 min remaining to read)

This article is also available in Chinese: 中文版. Browse all English articles.

Memory leaks and high memory usage are common problems in MySQL, and diagnosing them depends heavily on good memory-monitoring data. MySQL’s Performance Schema provides memory monitoring, but the granularity of PFS’s memory statistics is coarse, which makes it hard to pinpoint the exact code responsible.

The figure above shows the memory information monitored by PFS. Although the monitoring shows that a lot of memory is allocated on String::value and thd::main_mem_root, these are basic objects used in many places throughout MySQL, so we cannot infer from this which operation actually caused the memory usage. In addition, PFS itself has relatively high memory overhead and …

Benchmarking MyRocks vs. InnoDB in Memory-Constrained Environments It is a well-known fact in the database world that InnoDB is incredibly fast when the entire database fits into memory. But what happens when your data grows beyond your available RAM? MyRocks, built on RocksDB, is frequently recommended as a superior choice for environments constrained by memory, […]

Speed up your PHP application without changing a single query.

A few days ago I set out to answer a simple question: how much faster can a PHP app go if you drop a SQL cache in front of MySQL — without touching application code? The answer is below. On a four-table join aggregating revenue by category and region, Readyset served the same result 60x faster than MySQL. And all I did was change a port number.

This post walks through exactly what I did, step by step, so you can reproduce it yourself.

What Is Readyset?

Readyset is a SQL-aware caching engine that speaks the native MySQL wire protocol. Your PHP application connects to it the same way it connects to MySQL — same driver, same queries, same credentials. Underneath, Readyset proxies queries to your upstream database and, for the ones you choose to cache, serves …

A common source of instability in MySQL environments is the unexpected growth of memory usage at startup. You might set your innodb_buffer_pool_size to 16GB, only to find the process consuming 18GB or 20GB. This happens because MySQL enforces a strict geometric relationship between the total size, the number of instances, and the chunk size.

If these parameters are not aligned, the storage engine automatically rounds the total size upward. To maintain control over your server’s RAM, you must define innodb_buffer_pool_chunk_size with precision.

The Alignment Logic

The InnoDB buffer pool is organized into a hierarchy: the pool is split into instances to improve concurrency, and each instance is composed of chunks. According to the MySQL technical specifications, the total buffer pool size must be a multiple of this specific calculation:

Unit = …