MySQL 9.7 LTS: OpenTelemetry, JSON Duality Writes & Hypergraph Optimizer Now in Community

Release Overview

MySQL 9.7.0 LTS GA released April 21, 2024, with 9.7.1 security update June 16. This is the last sequentially numbered version; future releases will adopt year-month format (e.g., 26.7, 27.7). The release moves several enterprise-only operational features into the community edition.

LTS Does Not Mean Feature Freeze

LTS stabilizes APIs and behavior while patches continue. Innovation tracks advance separately. Users on 8.4 can upgrade directly to 9.7; 9.x innovation users can drop to 9.7. However, 8.0 cannot jump directly to 9.7 — must go through 8.4 first. The next LTS after 9.7 will be 28.4.

OpenTelemetry Enters Community Edition

Previously exclusive to Enterprise Edition, OpenTelemetry support now ships as a component in the community edition. Logs, metrics, and traces can be exported via OTLP. The component is installed and configured with SQL statements; endpoint and protocol variables require a server restart.

INSTALL COMPONENT 'file://component_telemetry';
SET GLOBAL telemetry.trace_enabled = ON;

Configuration in my.cnf:

[mysqld]
telemetry.otel_exporter_otlp_traces_endpoint=http://otel-collector:4318/v1/traces
telemetry.otel_exporter_otlp_metrics_endpoint=http://otel-collector:4318/v1/metrics
telemetry.otel_exporter_otlp_logs_endpoint=http://otel-collector:4318/v1/logs

After installation, SHOW VARIABLES LIKE 'telemetry%' reveals numerous enabled switches, making the database no longer a black box in monitoring systems.

JSON Duality View Gains Write Support

JSON Duality View, a key feature for document-relational duality, now supports INSERT, UPDATE, DELETE in the community edition (previously Enterprise only). The view definition uses WITH(INSERT, UPDATE, DELETE) to mark mutable fields; unmarked fields remain read-only. Auto-increment primary keys are supported.

CREATE OR REPLACE JSON RELATIONAL DUALITY VIEW customer_orders_dv AS
SELECT JSON_DUALITY_OBJECT(
  WITH(INSERT, UPDATE, DELETE)
  '_id': customer_id,
  'customer_name': name,
  'orders': (
    SELECT JSON_ARRAYAGG(JSON_DUALITY_OBJECT(
      WITH(INSERT, UPDATE, DELETE)
      'order_id': order_id,
      'product': product,
      'amount': amount))
    FROM orders
    WHERE orders.customer_id = customers.customer_id
  )
) FROM customers;

Inserting a document affects multiple base tables atomically:

INSERT INTO customer_orders_dv VALUES (
'{
  "_id": 1,
  "customer_name": "Alice",
  "orders": [
    {"order_id": 1, "product": "Laptop", "amount": 1299.99},
    {"order_id": 2, "product": "Mouse", "amount": 19.99}
  ]
}');
-- Query OK, 3 rows affected

A single statement can modify rows in both customers and orders tables; any error rolls back the entire operation, preserving atomicity and eliminating application-level DTO assembly and transaction orchestration.

Hypergraph Optimizer Available in Community

The traditional MySQL optimizer uses left-deep trees, limiting join-order search space for many-table queries. The Hypergraph optimizer models the entire query as a hypergraph and uses dynamic programming to explore a larger plan space. It was previously absent from community builds; in 9.7 it is included but disabled by default.

Enable globally or per-query:

SET PERSIST optimizer_switch = 'hypergraph_optimizer=on';

SELECT /*+ SET_VAR(optimizer_switch='hypergraph_optimizer=on') */
  c.name, SUM(o.amount)
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
JOIN order_items i ON i.order_id = o.order_id
GROUP BY c.name;

The author advises against enabling globally; instead, test on specific slow multi-join queries using EXPLAIN ANALYZE to verify plan improvement, as the new optimizer is not universally faster and depends on data distribution.

Replication and HA Observability Components Moved to Community

Four Enterprise Edition components are now in community: replication applier metrics, Group Replication flow-control statistics, Group Replication resource manager, and Group Replication primary election. This provides visibility into replica lag, queue backlogs, worker activity, and flow-control throttling. Automatic member eviction and rejoin on heartbeat anomalies are included, and primary election prefers the most up-to-date member to minimize data loss during failover.

A new variable replica_allow_higher_version_source allows a lower-version replica to replicate from a higher-version source, facilitating rolling upgrades without full cluster downtime.

Default Changes That Can Bite

innodb_log_writer_threads : Default logic now depends on log_bin and logical CPU count. With binlog enabled, 32+ cores are required for the writer threads to default on; without binlog, 4+ cores enables them. A 16-core server with binlog on will have redo log writer threads off by default, potentially causing write stalls for write-intensive workloads.

cpuset cgroup awareness : MySQL now respects CPU limits set via cpuset cgroups in containers, preventing it from seeing all host CPUs. This fix is especially valuable for Kubernetes deployments.

binlog_transaction_dependency_history_size : Maximum raised to 10 million; default increased to 1 million in 9.5, easing dependency tracking for large concurrent transaction replication.

Removed variables: replica_parallel_type and group_replication_allow_local_lower_version_join — old config files retaining them will cause startup errors.

Security Updates

caching_sha2_password

now supports PBKDF2 storage format with SHA-512 hashing; client changes are not required. Enterprise Edition adds dynamic data masking with policies attached to table columns, returning either original or masked values based on user/role — application-layer masking logic becomes unnecessary. This remains Enterprise-only.

Upgrade Recommendations

8.0 users : Upgrade to 8.4 first, clean deprecated variables and character-set issues, then move to 9.7. Pre-upgrade checks: innodb_log_writer_threads default, replication components installed, OTel endpoint in config.

8.4 users : Direct drop to 9.7 LTS; gain OTel, Hypergraph, and JSON write capabilities with no reason to wait.

9.x innovation users : 9.7 is the intended stable landing point. Teams with complex replication topologies and no MTS stress-testing should validate flow-control stats and primary election in a small cluster before rolling out.

Conclusion

MySQL 9.7 is not defined by a single headline feature but represents a concentrated delivery before the versioning scheme changes. The boundary between community and enterprise editions has been redrawn, an impact that will outlast any individual SQL feature.