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

If you use and operate MySQL, you’ve surely run into a strange slow query like this:

• An INSERT that’s normally instant took 1.3s, and the slow-query log shows no long lock wait.
• Every statement in a multi-statement transaction had already finished, yet the COMMIT alone took 1.3s.

When this happens, the most likely cause is a large transaction committing. Below is a simulated test: we used sysbench to simulate a normal workload, then ran a large UPDATE in the background every 5 seconds. You can see the large UPDATE severely hurts performance.

Root Cause

The …

About a year ago, we discussed how MyDumper refactored its locking mechanisms to move away from old, rigid flags and transitioned towards more flexible, streamlined execution. Since then, the MyDumper community hasn’t stood still.

In recent releases, the locking architecture was further standardized under a single overarching option: --sync-thread-lock-mode. Along with this modernization came a powerful new safety feature designed to give you lock-free thread synchronization without risking silent inconsistency: SAFE_NO_LOCK (merged in PR #2031).

Let’s explore the new thread-synchronization landscape and break down when you should use each mode.

What is --sync-thread-lock-mode?

Previously, flags like …

With the new LTS (Long Term Support) release of MySQL 9.7.0 https://dev.mysql.com/doc/relnotes/mysql/9.7/en/ , Dynamic Data Masking (DDM) is one of the new features introduced as part of Enterprise Edition. The recent blog by Mike Frank, MySQL Product Management Director, details why DDM is important in every industry where PII (Personal Identifiable Information) data is stored […]

As a junior once I asked a seasoned MySQL DBA (Abuelo) “How do you stay so calm in critical situations?”Abuelo DBA then uttered golden words: “Son, I keep my dirty…

The post InnoDB Flushing is simple – explained first appeared on Change Is Inevitable.

ducksdb-mysql-engine is an experimental build of MySQL 9.7 where a table you mark ENGINE=DuckDB answers analytical queries from DuckDB instead of InnoDB. Same server, same connection, no second copy of the data. On TPC-H at scale factor 10, InnoDB times out on 6 of the 22 queries and burns 1317 seconds on the 16 it finishes. The DuckDB tables run all 22 in about 15 seconds.

It’s an experiment, not production software. It patches mysqld and has rough edges, which we list at the end. Source is on GitHub under GPLv2: https://github.com/Percona-Lab/ducksdb-mysql-engine.

Why we made it

MySQL is great for transactions and slow at analytics. A wide GROUP BY over a few hundred million rows, or a six-way join, takes minutes on InnoDB. The usual fix is to copy the data into a column store and keep it in sync, so now you’re running two …

TL;DR If you use MD5(), SHA1(), or SHA() in MySQL today, start planning the move to SHA2(). Beginning with MySQL 9.6, MD5(), SHA1(), and SHA() are no longer native built-in SQL functions in the server binary. They are available through the Legacy Hashing Component: That component should be treated as a stopgap solution. It gives […]

A MySQL InnoDB Cluster provides high availability for a single database cluster using Group Replication. This works well for node failures inside the cluster, but disaster recovery usually requires another cluster in a separate location: another Kubernetes cluster, region, data center, or cloud.

This replica cluster needs to stay in sync with the primary, remain protected from accidental writes, and be ready to take over when you need to move traffic, either as a planned operation or during an outage.

InnoDB ClusterSet addresses this by linking multiple MySQL clusters into a single disaster-recovery topology. One cluster handles writes, while the others stay synchronized as read-only replicas.

Starting from v1.2.0, the Percona Operator for MySQL adds a new custom resource, PerconaServerMySQLClusterSet, which …

MySQL 26.7 is the initial MySQL Innovation release following the MySQL 9.7 LTS release and uses the new yy.mmCalVer versioning model for quarterly Innovation releases. This Early Access release provides a preview of selected functionality planned for the MySQL Community Server package and gives users an opportunity to evaluate upcoming changes before general availability. Download MySQL […]

Upstream MySQL published an out-of-schedule release this week with two high-severity CVE fixes. If you’re running Percona Server for MySQL 5.7 or 8.0 under Extended Lifecycle Support (ELS), the program we previously called Post EOL Support, you don’t have to do anything to qualify for them. We’ve already applied the fixes and re-released the affected ELS builds.

This is the point of ELS. When a major version reaches End of Life (EOL), the community stops shipping patches, but the databases running on it don’t stop mattering. ELS keeps critical bug and security fixes coming for versions that are past their EOL date, so you can stay on 5.7 or 8.0 on your own timeline instead of a deadline someone else set.

What we did

These CVE fixes landed upstream outside the normal cadence. Under ELS, customers are entitled to security fixes for the versions they run, so we pulled the patches into the 5.7 and 8.0 builds and …

Keeping up with the MySQL ecosystem is becoming increasingly challenging. Every release introduces new features, performance improvements, security enhancements, and cloud capabilities. While the official documentation is comprehensive, it is not always easy to quickly identify what really matters.

To help with that, I've published a new edition of my MySQL & MySQL HeatWave Report, covering the most important announcements around MySQL 9.7 LTS and MySQL HeatWave 9.7.
Slides: https://speakerdeck.com/freshdaz/mysql-and-mysql-heatwave-report-june-2026

The post MySQL & MySQL HeatWave Report – June 2026 first appeared on Data Daz (dasini.net) - Data Systems, AI, and Real-World Insights.