Oracle 23ai / MySQL 9.7 / PostgreSQL 19 发布：传统数据库的AI数据类型与合规升级解读

2026 年 9 月第二周，Oracle 23ai、MySQL 9.7 LTS 与 PostgreSQL 19 beta 三家传统 RDBMS 头部厂商几乎在同一方向集中发力：Oracle 23ai 推出“AI 数据类型”，MySQL 9.7 LTS 把 MD5/SHA1 移出核心并加入 PBKDF2，PostgreSQL 19 beta 则把在线 REPACK、并行 autovacuum、MultiXact 移除一起打包。三家各自的版本号虽然不同，但叙事重合度极高——“合规 + AI 友好”已经成为下一代大版本的统一主题。

一、Oracle 23ai：把 AI 数据类型做成“一等公民”

Oracle 在 2026 年 9 月围绕 23ai 集中披露了一批“为 AI 而生”的新数据类型：

1. 结构化多态类型（Structured Polymorphic Types）：同一字段可以容纳不同 schema 的子类型，AI 训练阶段常见的“标签 / 嵌入 / 文本混存”场景不再需要靠 ETL 拆分字段。
2. 混合文本-引用格式（Hybrid Text-Reference Formats）：把“原始文本 + 向量引用 + 外部嵌入模型版本号”打包进同一字段，Agent 可以根据模型版本号决定采用哪种嵌入方式做召回。
3. 动态 AI 输入的物化生命周期（Materialized Lifetimes）：对动态 AI 输入按生命周期进行物化，高频访问的嵌入缓存常驻内存，低频的自动落盘。这相当于把传统物化视图的思路套到了 AI 工作负载上。

9 月 8 日，Constellation Research 的 R "Ray" Wang 与 Holger Mueller 在对话中将这些变化概括为：Oracle 不再把数据库当作 AI 的底座，而是把数据库当作 AI 发生的地方之一——也就是说，数据库不只是喂数据的管道，还是直接执行 AI 工作负载的引擎。

二、MySQL 9.7 LTS：把“过时算法”和“过时认证”一次性清掉

MySQL 9.7.0 在 2026 年 4 月 GA，是 9.x 系列的收尾 LTS。从 9.7.0 开始，有两项变更会直接影响运维窗口：

1. MD5() / SHA1() 移出核心：从 MySQL 9.6.0 起，这两个函数被迁移到独立组件 classic_hashing。升级后函数默认不再存在，继续使用必须显式安装组件。驱动这一改动的核心原因是行业合规——这两种哈希算法已被判定为不可接受。
2. caching_sha2_password 新增 PBKDF2 存储：密码存储强度更高，切换到 PBKDF2 格式时连接端无需调整，管理员可以通过策略强制统一收敛。

此外，MySQL 26.7.0 开始启用 calendar-based versioning（YY.M.P），其中 26.7 对应 2026 年 7 月 GA；下一个 Innovation 版本是 26.10.0。9.7.x 与 8.4.x LTS 仍沿用旧的版本号，不套用新格式。升级路径上，官方仅支持 MySQL 8.4 LTS 原地升级到 9.7 LTS；MySQL 5.7 不能直接原地升级，必须分步执行或采用逻辑迁移。

关键的兼容性提醒：

• mysql_native_password 已被移除，所有账号必须使用 caching_sha2_password；老客户端驱动如果不支持，会直接报错。
• 新增 GIPK（自动生成不可见主键）能力，存量库升级前需要确认 GIPK 是否会与业务主键冲突。
• 旧版本的部分系统变量被删除，my.cnf 沿用旧配置会导致实例启动失败。

升级前必须完成以下事项：

• 全库扫描 MD5() / SHA1() 调用点，包括视图、生成列、存储程序、触发器、事件。
• 确认是否启用 classic_hashing 组件。
• 盘点 caching_sha2_password 的覆盖范围与切换顺序。
• 评估 PBKDF2 强制偏好策略的回退路径。

三、PostgreSQL 19 beta：把运维痛点一次性解决

PostgreSQL 19 在 2026 年中期进入 beta，几个对 DBA 直接可见的改进如下：

1. 在线 REPACK：以前的 VACUUM FULL 需要 ACCESS EXCLUSIVE 锁，19 beta 起可以通过在线 REPACK 重写表而不阻塞读写。DBA 终于不用再挑凌晨停机窗口做表瘦身了。
2. 并行 autovacuum：多 worker 并行清理，面对“大表 + 高并发更新”的场景（例如订单表、用户表），能明显缩短 vacuum 周期。
3. 移除 MultiXact 上限：这是一个存在多年的“怪味”问题——MultiXact 用于跟踪多个事务同时锁同一行的场景，但此前有上限；高并发加大量外键引用的表，经常触发“MultiXact 溢出”进而导致 freezing 问题。19 beta 直接移除了这个上限。

PostgreSQL 19 同时配套发布了以下内容：

• PostgreSQL Migrator 1.0（Dalibo 团队）——经过一年 beta/RC 后正式稳定，支持 Oracle 11g–26ai、MySQL 8.4+、MariaDB 10+ 迁移到 PostgreSQL 16–19。
• PostGIS 3.7.0rc2——适配 PostgreSQL 14–19 beta3 + GEOS 3.15 + SFCGAL 2.3.0+。
• pg_vault_tde 1.7.1——修正 TOAST AAD 派生问题，升级前需要导出旧表数据。

此外，PostgreSQL 18 已正式成为当前 major 版本（18.6），PostgreSQL 14 将在 2026 年 11 月 EOL。仍在 14 上的用户需要尽快规划升级路径。

四、三家的共同主题：合规 + AI 友好

把这三件事并排看，传统 RDBMS 头部厂商正在用同一套叙事推进下一代版本：

合规方面，三家都在做“减法”：把过时的算法、过时的认证方式、过时的限制一次性清掉。AI 友好方面，三家都在做“加法”：加新数据类型（Oracle 多态类型、MySQL VECTOR、PostgreSQL 在 beta 中新增的内置 AI 函数），加对 AI 工作负载的性能优化（PostgreSQL 并行 autovacuum 服务于高频更新表），加对 AI 数据流的治理（Oracle 物化生命周期、PostgreSQL Migrator 的迁移友好）。

五、对国产数据库的启示

国内主流 RDBMS（OceanBase、PolarDB、TiDB、openGauss、GaussDB、达梦 DM）也在跟进类似方向，但落地节奏可以借鉴国际厂商的三点经验：

1. “移除过时”要明确时间表：MySQL 把 MD5/SHA1 移出核心、移除 mysql_native_password 的时间表都写在了 release notes 里。国产数据库如果要作类似的“减法”，建议提前 12 个月公告，给生态留足适配时间。
2. “AI 数据类型”要和应用绑定：Oracle 把“多态类型 + 嵌入引用”绑定为同一字段，国产数据库可以更激进——把 VECTOR / 嵌入缓存 / 物化生命周期做成同一概念，对外只暴露“AI 列”这一种入口。
3. 升级工具链要强：PostgreSQL Migrator 1.0 历经一年 beta 才稳定，专门服务从 Oracle / MySQL / MariaDB 迁出。国产数据库做“替代 Oracle / MySQL”的市场，迁移工具的成熟度直接决定市占率天花板。

六、给 DBA 的结论

对一线 DBA 来说，针对三个版本号的具体动作是：

• MySQL 8.0 用户：已 EOL（2026 年 4 月），应尽快迁移到 8.4 LTS 或 9.7 LTS。
• PostgreSQL 14 用户：2026 年 11 月 EOL，建议直接迁移到 18（18.6），或试迁 19 beta。
• Oracle 用户：评估 23ai 新类型对 AI 工作负载的实际收益，重点看“多态类型”对 ETL 链路的简化效果。
• 任何正在跑 MD5() / SHA1() 的 MySQL 实例：升级前必须先盘点调用点，否则升级后对应的函数会直接消失。

数据来源：

• Oracle 23ai "Unlocks AI Evolution" 系列博客（ProLabs / Unibots / DanielWalters / PennDS）
• Constellation Research："How Oracle Is Reinventing the Database for the AI Era"（2026-09-08）
• MySQL 9.7.0 LTS 升级实战（51CTO 教程）
• MySQL 26.7.0 calendar versioning 解析（程序员茄子）
• Postgres vs MySQL 2026 版本对照（alekseialeinikov.com）
• PostgreSQL 19 beta 功能整理（Bubble.ro 2026-09-14）

如果觉得这些版本迁移路线太复杂，不妨在云栈社区和同行一起交流。