Overview
Servers Tested:
Tier Configurations:
View Results
The benchmark reports are available as interactive HTML pages at:
https://percona-lab-results.github.io/2026-pgo/index.html
Performance …
[Read more]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 …
[Read more]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)
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 …
[Read more]
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 = …
[Read more]I recently got into a bit of a debate about standardizing MySQL 8.4’s internal temporary table configuration. We wanted to cap memory usage efficiently, but relying on “rules of thumb” isn’t enough when production stability is at stake.
The main confusion was about how per-query limits fight with global limits. So, rather than guessing, I decided to break a sandbox environment to see exactly where the bytes go—and confirm the findings against the official documentation.
The Theory: Individual vs. Collective
Before I run the scripts, let’s establish the rules based on the MySQL 8.4 Reference Manual. There is a critical distinction between “individual” and “collective” limits.
1. tmp_table_size (The Cup)
This is the limit for a single table. According to the …
[Read more]
As databases grow, DBAs and developers often face a tough
choice:
+ Keep historical data in production tables and risk slow
queries
+ Archive it and lose fast access
With HeatWave, you don’t have to choose. You can archive old partitions, keep recent data in production, and still run lightning-fast queries across all your data.
The post Archive Smarter, Query Faster: Unlocking MySQL Performance with HeatWave first appeared on Data Daz (dasini.net) - Data Systems, AI, and Real-World Insights.