MySQL 9.7.0 LTS 升级：MD5() 会先掉线，认证存储格式也换了
MySQL 9.7.0 GA 意味着 9.x innovation 系列收尾，转入 9.7.x LTS 线。升级这个版本，真正会在变更窗口里卡住运维的是两件事：9.6.0 起被移出核心的 MD5()/SHA1()，以及 caching_sha2_password 新增的 PBKDF2 存储格式。其余能力多为增量，不会让实例起不来。
MD5() 和 SHA1() 不再随核心提供
MySQL 9.6.0 的 Security Notes 里有一条 Important Change：MySQL 把 MD5() 和 SHA1() 这两个 SQL 函数迁到了单独组件。升级到 9.7.0 后函数默认不存在，继续用必须安装 classic_hashing 组件。驱动这个改动的是行业合规要求——避免继续提供已被判定为不可接受的哈希算法。同一批安全改动里，MySQL Server 使用的 OpenSSL 算法也换成了非废弃实现。
影响面比手写一条 SELECT MD5(...) 宽得多。要一并检查：
- 视图定义、生成列
- 存储过程 / 存储函数、触发器、事件
- 应用侧拼接出来、不落在库对象里的 SQL
升级前先把这些对象扫一遍，需要保留函数的，在测试实例上装组件验证，再决定要不要把这一步写进正式升级流程。
caching_sha2_password 支持 PBKDF2 存储格式
认证侧这次给 caching_sha2_password 加了 PBKDF2 存储格式（SHA512），密码存储强度更高。对运维来说要点有两个：
- 迁移不需要改客户端。用户切换到新存储格式时，连接端不用做任何调整。
- 管理员可以强制偏好格式。即使在混合环境里，也能把账号统一收敛到 PBKDF2 格式，而不是等用户自己改。
升级前先盘一遍账号：哪些走 caching_sha2_password、哪些还在旧插件上，确认切换窗口和顺序。强制格式的策略一旦打开，回退成本要提前想清楚。
社区版的 8 项新增能力
按 4 个方向分布：
复制可观测性与高可用行为
- Flow-control 监控
- 多线程 applier 扩展统计
- Automatic Eviction & Rejoin
- Up-to-date Aware Primary Election
遥测与可观测性集成
- Telemetry / OpenTelemetry 支持
现代应用开发
- MySQL JSON Duality Views
查询优化与性能
- Hypergraph Optimizer
- Profile-Guided Optimization（PGO）
企业版：动态数据脱敏与审计
动态数据脱敏的核心变化是把 masking policy 直接挂到基表列上，查询时由 MySQL 根据执行用户或当前生效角色，返回原始值或掩码值。配套的 SQL 与语法扩展：
- 新增
CREATE MASKING POLICY、DROP MASKING POLICY、SHOW CREATE MASKING POLICY CREATE TABLE/ALTER TABLE ... ADD COLUMN/ALTER COLUMN支持 masking policy- 新增门禁函数
CURRENT_ROLE_IN(role1,role2,...)和CURRENT_USER_IN(user1,user2,...)
审计侧两项运维改进：
- 审计日志按时间轮转
- 审计日志 filter recovery mode，由
audit_log.filter_recovery_mode控制，取值为LOG_ALL_IF_INVALID_FILTER_DETECTED、LOG_NOTHING_IF_INVALID_FILTER_DETECTED、ABORT_IF_INVALID_FILTER_DETECTED
带脱敏策略的列在 ALTER 时也要一起考虑策略归属；审计日志轮转周期和 filter recovery 的行为，最好在升级前就定好，避免升级后才发现日志落盘策略变了。
升级前检查清单
- 全库扫描 MD5()/SHA1() 调用点，含视图、生成列、存储程序、触发器、事件。
- 确认是否需要 classic_hashing 组件，并在测试实例验证安装流程。
- 盘点账号使用的认证插件，确认 caching_sha2_password 的覆盖范围与切换顺序。
- 确认是否启用 PBKDF2 强制偏好格式，规划回退路径。
- 企业版确认 masking policy 涉及的库表，以及审计日志轮转与 filter recovery mode 配置。