Latest in branch 9.7
9.7.0
Released 07 Apr 2026
(1 month ago)
SoftwareMySQL
Branch9.7
StatusLTS
Supported
Initial release9.7.0
07 Apr 2026
(1 month ago)
Latest release9.7.0
07 Apr 2026
(1 month ago)
End of
premier support
21 Apr 2031
(Ends in 4 years, 11 months)
End of
extended support
21 Apr 2034
(Ends in 7 years, 11 months)
Release noteshttps://dev.mysql.com/doc/relnotes/mysql/9.7/en/news-9-7-0.html
Source codehttps://github.com/mysql/mysql-server/tree/mysql-9.7.0
Documentationhttps://dev.mysql.com/doc/refman/9.7/en/
Downloadhttps://dev.mysql.com/downloads/mysql/
MySQL 9.7 ReleasesView full list

What Is New in MySQL 9.7 -- Summary of Changes

MySQL 9.7 ships a focused set of changes across optimizer, InnoDB, JSON, authentication, replication, and audit subsystems. The headline story is that two previously Enterprise-only features -- the Hypergraph Optimizer and several Group Replication components -- are now fully available in Community Edition.

Category Change Edition
Optimizer Hypergraph Optimizer now available in Community Edition Community
JSON DML operations (INSERT, UPDATE, DELETE) on JSON Duality Views in Community Edition Community
JSON Auto-increment columns now supported in JSON Duality View DML All
Authentication PBKDF2 storage format added to caching_sha2_password All
Replication New replica_allow_higher_version_source variable for cross-version replication All
InnoDB cpuset cgroup support for accurate CPU count All
InnoDB Clone plugin supports consecutive LTS versions above 9.7.0 All
InnoDB FTS index memory usage optimized for large tables All
Audit Log New audit_log.rotate_on_time for time-based log rotation All
Audit Log New audit_log.filter_recovery_mode for invalid filter handling All
Components (Community) Replication Applier Metrics, Group Replication Flow Control Stats, Resource Manager, Primary Election Community
Components (Community) Telemetry component moved to Community Edition Community
Packaging PGO builds now supported for RPM on SLE/openSUSE and Fedora All
Packaging Bundled OpenSSL updated to 3.5.5, zlib updated to 1.3.2 All
Bug Fixes Date/time function correctness (TIMEDIFF, FROM_DAYS, DAYNAME, ADDDATE, CAST), InnoDB multi-value indexes, INTERSECT, Atomic DDL LOCK=NONE All

Hypergraph Optimizer -- Is It Finally in Community Edition?

Yes. The Hypergraph Optimizer is now available in MySQL Community Edition with 9.7. Previously it was gated behind Enterprise. This is one of the most practically useful additions in this release for anyone running complex analytical queries.

You can switch it on at multiple scopes without restarting the server:

-- Session scope (affects only your current connection)
SET optimizer_switch='hypergraph_optimizer=on';

-- Global scope (affects all new connections)
SET GLOBAL optimizer_switch='hypergraph_optimizer=on';

-- Persist across restarts
SET PERSIST optimizer_switch='hypergraph_optimizer=on';

-- Per-statement hint (no side effects)
SELECT /*+ SET_VAR(optimizer_switch='hypergraph_optimizer=on') */ *
FROM orders o
JOIN order_items i ON o.id = i.order_id;

In practice, the Hypergraph Optimizer shines on multi-join queries where the legacy optimizer tends to pick suboptimal join orders. It models the query plan as a graph problem instead of left-deep trees, which leads to better cardinality estimates on large datasets. Test it on your heaviest read queries before committing globally.

JSON Duality Views Get Full DML Support in Community Edition

Community Edition users can now run INSERT, UPDATE, and DELETE against JSON Duality Views -- not just DDL. Previously this capability was restricted. This brings Community Edition to parity with Enterprise for this feature.

On top of that, auto-increment columns are now usable as primary keys in Duality View DML across all editions. You no longer have to manually supply a PK value on insert:

-- Insert without providing the PK -- auto-increment handles it
INSERT INTO orders_duality_view
  VALUE ('{"customer_id": 42, "status": "pending"}');

-- Update via the JSON view
UPDATE orders_duality_view
SET data = JSON_SET(data, '$.status', 'shipped')
WHERE data->>'$.id' = '1001';

Duality Views let you expose relational tables as JSON documents without giving up ACID guarantees. The DML support closes the last major gap that made them impractical for write-heavy workloads in Community Edition.

Authentication Upgrade -- PBKDF2 for caching_sha2_password

MySQL 9.7 adds PBKDF2 with SHA-512 as a storage format option inside caching_sha2_password. This is a meaningful upgrade: PBKDF2 is a key-derivation function designed to be computationally expensive, making brute-force attacks against stored hashes significantly harder.

The migration path is smooth -- existing clients do not need changes. Administrators can enforce the preferred storage format server-side, so new and rotated passwords automatically use PBKDF2 while existing connections continue to work. This is the kind of change you want to roll out proactively rather than wait for an incident to prompt it.

See the Caching SHA-2 Pluggable Authentication documentation for configuration details.

Replication -- Cross-Version Support and Community Component Upgrades

A new system variable replica_allow_higher_version_source lets you explicitly allow replication from a higher-version source into a lower-version replica. By default MySQL blocks this to prevent compatibility issues, but there are real upgrade scenarios -- like blue/green switchovers -- where you need it temporarily.

-- Allow replication from a newer source
SET GLOBAL replica_allow_higher_version_source = ON;

Four Group Replication components previously locked to Enterprise are now available in Community Edition:

  • Replication Applier Metrics Component -- exposes detailed apply-side metrics via performance schema
  • Group Replication Flow Control Statistics Component -- visibility into flow control events
  • Group Replication Resource Manager Component -- CPU/thread resource management for GR
  • Group Replication Primary Election Component -- hooks into primary election lifecycle

The Telemetry component also moves to Community Edition in this release. If you run Community-based Group Replication clusters, these additions give you production-grade observability without an Enterprise license.

InnoDB -- cgroup Awareness, Clone Plugin, and Memory Fixes

MySQL Server now correctly reads cpuset cgroup constraints. When the server runs inside a container or VM where CPUs are limited via cpuset-cpus, it will now calculate the available logical CPU count accurately. This directly affects thread pool sizing and InnoDB parallel thread decisions -- previously the server might spawn more threads than the host physically allowed.

The Clone plugin adds support for cloning between consecutive LTS versions above 9.7.0. This matters for rolling upgrades: you can clone data from a 9.7 node to a 9.8 node (when available) without full dump/restore cycles. Check the Clone Plugin Limitations page for the exact version matrix.

Memory usage during full-text search (FTS) index construction on large tables has been reduced. Running CREATE INDEX with high innodb_parallel_read_threads values no longer risks filling the disk due to excessive temporary space -- that bug is now fixed.

Additional InnoDB fixes cover multi-value indexes, TRUNCATE TABLE edge cases, assertion failures during maximum index record size calculation, and a startup failure when cgroups memory limits were extremely high with --innodb-dedicated-server=ON.

Audit Log -- Time-Based Rotation and Filter Recovery

Two new audit log capabilities ship in 9.7. First, time-based log rotation via audit_log.rotate_on_time -- you can now rotate the audit file on a schedule rather than only by size. This is easier to reason about for retention policies tied to time windows.

Second, audit_log.filter_recovery_mode controls what happens when the server starts and finds an invalid filter configuration in the table. You choose one of three behaviors:

  • LOG_ALL_IF_INVALID_FILTER_DETECTED -- replace the bad filter with a catch-all and keep running
  • LOG_NOTHING_IF_INVALID_FILTER_DETECTED -- replace with a filter that logs nothing
  • ABORT_IF_INVALID_FILTER_DETECTED -- refuse to start

Before this fix, a corrupted filter configuration could prevent the server from starting or silently drop audit events. The default behavior now ensures audit coverage continues even during configuration failures. A separate bug fix also relaxes .gz header validation so ordinary gzip files pass the audit log file processing checks.

Date/Time Function Correctness Fixes

Several date and time functions had bugs that could silently return wrong results. These are fixed in 9.7 under WL #16895:

  • TIMEDIFF() returned a wrong result when the first argument was DATETIME and the second was DATE
  • TIMEDIFF() did not return NULL for unsupported input values
  • FROM_DAYS() handled out-of-range values and values below 366 inconsistently
  • DAYNAME() returned the day number instead of the day name when used inside an arithmetic expression
  • ADDDATE() returned an incorrect result when the first argument was year zero (0000)
  • CAST() of a year column returned the wrong result

These are the kind of silent data correctness bugs worth checking if you do date arithmetic in queries or stored procedures. Run a validation pass against known expected outputs if your application relies on any of these functions with edge-case inputs.

Packaging -- OpenSSL 3.5.5, zlib 1.3.2, PGO RPM Support

The bundled OpenSSL library is updated to 3.5.5 for platforms where MySQL ships its own SSL. The bundled zlib moves to 1.3.2. Both are maintenance updates that address known CVEs in the previous versions -- no action needed beyond upgrading MySQL itself.

Profile Guided Optimization (PGO) builds, which produce measurable throughput improvements by compiling with real workload profiles, now extend to RPM packages on SLE/openSUSE and Fedora. Add --define=with_pgo 1 to your rpmbuild command to enable it. PGO was already available for other platforms; this closes the gap for enterprise Linux distributions commonly used in production.

FAQ

Can I use the Hypergraph Optimizer safely in production with MySQL 9.7 Community Edition?
You can enable it and it is production-capable, but treat it as a gradual rollout. Enable it at session scope first and compare query plans with EXPLAIN FORMAT=TREE against your heaviest queries. The Hypergraph Optimizer generally improves multi-join performance, but any optimizer change can shift plan choices -- validate on staging before flipping the global switch.

Do I need to update my application clients to use the new PBKDF2 authentication format?
No. The PBKDF2 format is a server-side storage change inside caching_sha2_password. Existing clients authenticate the same way -- the protocol handshake does not change. New or rotated passwords will use the stronger format automatically once it is configured. The only action required is on the server/administrator side.

What does replica_allow_higher_version_source actually unlock -- and is it safe to leave ON permanently?
It allows a replica running an older MySQL version to receive replication events from a newer source. This is useful during rolling upgrades where you temporarily have mixed versions in a cluster. Leaving it ON permanently is not recommended -- MySQL version guarantees flow downward, not upward, and unanticipated event format differences could cause silent data issues. Enable it only for the duration of your migration window.

My containers limit CPUs via cpuset -- does MySQL 9.7 automatically pick this up, or do I need to configure something?
It is automatic as of 9.7. The server reads the cpuset-cpus cgroup controller at startup and adjusts its logical CPU count accordingly. No configuration change is needed. If you were previously working around this by manually setting innodb_read_io_threads, innodb_write_io_threads, or thread pool sizes, review those settings -- the server may now calculate better defaults on its own.

JSON Duality Views DML is now in Community Edition -- what is the write performance overhead compared to direct table inserts?
Duality Views add a JSON serialization/deserialization layer on top of relational storage, so writes are slightly heavier than direct table DML. In practice the overhead is acceptable for most workloads because the underlying storage is still fully relational and ACID-compliant. The tradeoff is flexibility -- you get a JSON API over a normalized schema. For insert-heavy workloads at extreme scale, benchmark directly against your data model before committing to Duality Views as your primary write path.

References

Releases In Branch 9.7

VersionRelease date
9.7.007 Apr 2026
(1 month ago)