MySQL 9.7.0 LTS 在 2026 年 4 月 21 日发布，同一天 8.0.46 成为 8.0 最后的小版本，8.0 正式 EOL 对于社区版而言，这是一次实质性的升级：把五个企业版组件放到社区版中来、把 Hypergraph 优化器放进社区版里去、支持 DML 的 JSON Duality View 放入社区版中来 先确定好升级路线8.0 不再发布安全补丁了，继续运行就相当于把风险留给了生产 保守路线为 8.0 升到 8.4LTS，大部分情况下不需要做改动；新的特性就用 9.7 LTS；已经稳定在 8.4 的话，不要因为版本号而强行升级 在进行升级之前使用 MySQL Shell 来检查兼容性，并把结果输出为 JSON 格式可以直接被放入到 CI 系统中 # 只读检查，不能修改数据；--target-version 指定目标LTS
mysqlsh -- util check-for-server-upgrade --user=root --host=127.0.0.1 --port=3306 \
--target-version=9.7.0 --output-format=JSON9.7 是 LTS 线，5 年 Premier 加上 3 年 Extended，在做生产基线没有问题 五个企业版组件已经下放到各个地方复制 Applier 指标、Group Replication 流控统计、资源管理器、主节点选举，再加上 Telemetry，全部进入社区版 -- 复制Applier指标表到performance_schema中
INSTALL COMPONENT 'file://component_replication_applier_metrics' ;
-- OpenTelemetry 指标、链路、日志
INSTALL COMPONENT 'file://component_telemetry' ;
-- 注意：当 replica_parallel_workers=0 时，Applier 指标表会为空
SELECT * FROM performance_schema.replication_applier_metrics;
SELECT * FROM performance_schema.replication_applier_progress_by_worker;Telemetry 直接发给 otel-collector，不需要自己去写 exporters -- collector 对应的 HTTP 端口
SET GLOBAL telemetry.otel_exporter_otlp_traces_endpoint = 'http://otel-collector:4318/v1/traces' ;
SET GLOBAL telemetry.trace_enabled = ON ;Hypergraph 优化器经典的优化器是基于左深树的，join 的顺序只能在链式结构中查找，bushy 计划和排序属性很难参与到代价比较当中 Hypergraph 把表当作节点，把 join 谓词看作是边，并且用动态规划来枚举连通子图，再用 hash join 与嵌套循环在同一个代价模型中进行比较 在官方 TPC-DS SF1 的 101 条查询中，有 77 条变快了，24 条变慢了，几何平均提升率为 22.45%，但是有 14 条退化程度超过了 50%，因此默认关闭 三种开启方式的影响程度由小到大 -- 1. 会话级别，在当前连接中进行验证
SET SESSION optimizer_switch= 'hypergraph_optimizer=on' ;
-- 2、一条SQL语句，并且使用SET_VAR hint，不会影响到其他的语句
SELECT /*+ SET_VAR(optimizer_switch='hypergraph_optimizer=on') */
c.id, count (* ) as cnt
FROM orders AS o JOIN customers AS c ON c.id = o.customer_id
GROUP BY c.id ORDER BY cnt DESC LIMIT 10 ;
-- 3、持久化，在重启之后仍然有效，全量前一定要做压测
SET PERSIST optimizer_switch = 'hypergraph_optimizer=on' ;相同的 SQL 跑两次 EXPLAIN ANALYZE 来比较实际行数以及耗时，并且只有确认速度加快的语句使用 hint 固定 -- 基线跑一次，然后开会话开关重跑，比较 actual time 和 rows
EXPLAIN ANALYZE SELECT ...;
SET SESSION optimizer_switch= 'hypergraph_optimizer=on' ;
EXPLAIN ANALYZE SELECT ...;sysbench 外部测试中 read-only-distinct 提升了 26%、range=10000 提升了 15%，主要体现在多表连接和带有排序的聚合上 JSON Duality View 支持写入社区版之前只能创建视图，只能查看数据，9.7 版本补齐了 INSERT、UPDATE、DELETE 等功能，并且支持自动生成主键（省略）。 CREATE TABLE customers(customer_id int primary key ,name varchar (100 ));
CREATE TABLE orders(
order_id int auto_increment primary key ,
customer_id int ,
amount DECIMAL (10 ,2 ),
FOREIGN KEY (customer_id) references customers(customer_id)
);
-- 在WITH语句中定义的操作才可以被书写，没有被声明的对象默认为只读
CREATE OR REPLACE JSON RELATIONAL DUALITY VIEW order_dv AS
SELECT JSON_DUALITY_OBJECT(WITH (INSERT ,UPDATE ,DELETE )
'_id'  rder_id,
'amount' : amount,
'customer' : (
SELECT JSON_DUALITY_OBJECT(WITH (INSERT ,UPDATE ))
'customer_id' : customer_id, 'name' : name
FROM customers WHERE customers.customer_id = orders.customer_id
)
) FROM orders;
-- order_id 自增，JSON 中可以省略
INSERT INTO order_dv VALUES ('{"amount":1299.99,"customer":{"customer_id":1}}' );
-- 使用 _id 来定位文档，只可以修改一条
UPDATE order_dv SET data = '{"_id":1,"amount":999.00}'
WHERE JSON_EXTRACT(data, '$._id' )= 1 ;
DELETE FROM order_dv WHERE JSON_EXTRACT(data, '$._id' ) = 1 ;一条视图 DML 会被拆分成多个基表子语句，并且整个操作是原子提交、失败全部回滚，触发器和外键级联照常执行 滚动升级和容器 CPUreplica_allow_higher_version_source 默认为 ON，可以接受低版本的数据从库连接到高版本主库 -- 先升主库，观察之后再逐个滚从库
SET GLOBAL replica_allow_higher_version_source= ON ;cpuset、cgroup 也得到了正确的识别，在 Kubernetes 中 limit 为 4 核不会按照宿主机 32 核来计算线程池 密码存储换 PBKDF2-SHA512caching_sha2_password 新增 PBKDF2 存储格式，默认仍然是 CRYPT5，客户端不需要做任何修改 -- 新密码或者重置密码的时候用PBKDF2-SHA512
SET GLOBAL caching_sha2_password_storage_format= 'PBKDF2_SHA512' ;
-- 开启强制之后，存量账号登录会要求马上修改密码，并不会直接锁定
SET GLOBAL caching_sha2_password_enforce_storage_format= ON ;主库生成的哈希直接复制到从库中，各个节点的配置需要保持一致，否则同一个账号在不同的节点上会有不同的表现 企业版和向量检索Dynamic Data Masking 仍然属于企业版，策略绑定到列上，按照执行用户或者角色返回掩码值，应用程序不需要修改 向量检索 9.7 还不是 GA，官方正在按照创新版来铺设道路，所以现在不要为了向量迁移数据库 结论8.0 尽快安排升级排期，在新的项目中使用 9.7 LTS 版本；复制指标、Telemetry 等先接好，Hypergraph 按照 SQL 灰度，PBKDF2 跟着改密码的频率
| 
发表于