【人工智能专题】PolarDB 深度解析：存算分离到 AI Lakebase，云原生数据库的架构演进与实战指南

A.说学逗唱的Coke2026-10-09 9:15

PolarDB 深度解析：存算分离到 AI Lakebase，云原生数据库的架构演进与实战指南

    • [前言：为什么值得重新审视 PolarDB（2026 视角）](#前言：为什么值得重新审视 PolarDB（2026 视角）)
    • 一、产品全景：三大引擎与四种输出形态
      • [1.1 三大引擎](#1.1 三大引擎)
      • [1.2 四种输出形态](#1.2 四种输出形态)
      • [1.3 三大引擎对比](#1.3 三大引擎对比)
    • 二、核心架构解析：从存算分离到三层解耦
      • [2.1 存算分离的原理](#2.1 存算分离的原理)
      • [2.2 架构图](#2.2 架构图)
      • [2.3 三层解耦：CXL 内存池化](#2.3 三层解耦：CXL 内存池化)
      • [2.4 与传统架构对比](#2.4 与传统架构对比)
    • [三、Serverless 弹性实战：秒级伸缩与成本优化](#三、Serverless 弹性实战：秒级伸缩与成本优化)
      • [3.1 Serverless 的原理与边界](#3.1 Serverless 的原理与边界)
      • [3.2 成本优化三板斧](#3.2 成本优化三板斧)
      • [3.3 Serverless 配置示例](#3.3 Serverless 配置示例)
    • [四、HTAP 实战：IMCI 列存索引 100 倍加速](#四、HTAP 实战：IMCI 列存索引 100 倍加速)
      • [4.1 IMCI 的原理](#4.1 IMCI 的原理)
      • [4.2 SQL 实战](#4.2 SQL 实战)
    • [五、AI 就绪能力：AI Lakebase 与库内 RAG（2026 新重点）](#五、AI 就绪能力：AI Lakebase 与库内 RAG（2026 新重点）)
      • [5.1 AI Lakebase 的"4+1"架构](#5.1 AI Lakebase 的"4+1"架构)
      • [5.2 库内 RAG 实战（PolarDB MySQL 版 + IMCI）](#5.2 库内 RAG 实战（PolarDB MySQL 版 + IMCI）)
      • [5.3 库内 RAG 实战（PolarDB PG 版 polar_ai 扩展）](#5.3 库内 RAG 实战（PolarDB PG 版 polar_ai 扩展）)
      • [5.4 传统 RAG vs 库内 RAG](#5.4 传统 RAG vs 库内 RAG)
    • [六、迁移实战：RDS MySQL 到 PolarDB 完整流程](#六、迁移实战：RDS MySQL 到 PolarDB 完整流程)
      • [6.1 创建集群的关键配置](#6.1 创建集群的关键配置)
      • [6.2 命令行连接验证](#6.2 命令行连接验证)
      • [6.3 DTS 迁移三步](#6.3 DTS 迁移三步)
      • [6.4 应用连接示例](#6.4 应用连接示例)
      • [6.5 切换与回滚要点](#6.5 切换与回滚要点)
      • [6.6 迁移常见坑](#6.6 迁移常见坑)
    • 七、横向对比与选型决策
      • [7.1 四大云原生数据库对比](#7.1 四大云原生数据库对比)
      • [7.2 选型决策要点](#7.2 选型决策要点)
      • [7.3 客户案例数据](#7.3 客户案例数据)
    • 八、踩坑记录与最佳实践
    • 九、总结与展望
    • 参考资料

前言：为什么值得重新审视 PolarDB（2026 视角）

过去两年，数据库行业的需求结构发生了实质性变化。变化不是来自传统 OLTP 场景的升级，而是来自 AI 应用落地带来的三类新压力：

  1. 突发流量。AI 应用的调用模式与 Web 应用完全不同，一个爆款 Agent 应用上线当天 QPS 可能增长 50 倍，分钟级的弹性响应成了硬指标；
  2. HTAP 混合负载。AI 应用普遍需要"实时写入 + 实时分析"同时进行，比如客服系统的会话写入与质量分析报表，传统方案要维护两套系统（MySQL + ClickHouse）做 ETL 同步；
  3. 多模态数据。文本、向量、图片需要统一存储和检索，RAG 架构要求数据库本身具备向量检索能力，而不是把数据搬出去给独立的向量数据库处理。

这三类压力恰好对应 PolarDB 的三个核心能力：Serverless 秒级弹性、IMCI 列存索引的 HTAP 能力、AI Lakebase 的库内 RAG。这也是我把它拿出来重新审视的原因------它不是"又一个 MySQL 兼容云数据库"，而是架构层面有代际差异的产品。

先给出几个硬数据，来自阿里云官方发布：

  • 2025 年 3 月，PolarDB 在 TPC-C 基准测试中创下每分钟 20.55 亿笔交易（tpmC）的世界纪录，同时以单位成本 0.8 元人民币创下性价比纪录；
  • 全球 2 万+ 企业客户，覆盖金融、汽车、政务、互联网行业；
  • 截至 2025 年 12 月 Gartner 报告，连续 6 年入选云数据库管理系统领导者象限。

PolarDB 是阿里云 2017 年发布的国内首款云原生存算分离数据库，2018 年商业化，2021 年 PolarDB-PG 与 PolarDB-X 开源且内核与商业版一致。2026 年 1 月，阿里云发布了 AI Lakebase------把湖仓一体、向量检索、库内模型推理整合进数据库内核，这是本文着墨最多的新方向。

本文结构：第一、二章讲产品全景与存算分离架构，这是理解 PolarDB 的地基；第三、四章讲 Serverless 与 IMCI 两个实战场景；第五章深入 AI Lakebase 与库内 RAG，附完整 SQL 流程；第六章给出 RDS MySQL 迁移 PolarDB 的完整操作流程；第七章横向对比 Aurora、TDSQL-C、TiDB 并给选型建议；第八章是踩坑记录。

一、产品全景：三大引擎与四种输出形态

很多文章把 PolarDB 当成一个产品来讲，这是不准确的。PolarDB 实际上是"一个架构理念 + 三个引擎 + 四种输出形态"的组合。

1.1 三大引擎

PolarDB MySQL 版：存量用户最多、生态最成熟的引擎。100% 兼容 MySQL 5.6/5.7/8.0，支持一写多读、多写多读和 HTAP（列存索引 IMCI）三种形态。对绝大多数从 RDS MySQL 或自建 MySQL 迁移的用户，这是默认选项。

PolarDB PostgreSQL 版：100% 兼容 PG 11/14/15/17，同时高度兼容 Oracle 语法。这里有个容易被忽略的点：PG 版对 Oracle 语法的兼容不是简单的关键字映射，配合阿里云的 ADAM（Advanced Database & Application Migration）迁移工具，可以把 Oracle 的存储过程、触发器做自动评估与改写，官方数据是迁移成本降低 90%。对于从 Oracle 去O 的企业，这条路的工程量远小于手工重写。

PolarDB-X 分布式版：面向 PB 级数据和超高并发的分布式引擎，采用 Shared-nothing + 存算分离混合架构，支持集中式与分布式一体化部署。它解决的是单机写瓶颈问题------当一写多读的"写"扩展到头（写还是落在一个主节点），PolarDB-X 通过水平拆分让写能力线性扩展。

1.2 四种输出形态

输出形态 说明 典型客户
公有云 标准云服务，10000+ 客户 互联网、中小金融
专有云 部署在客户自有云环境 政务、大型金融
DBStack 轻量化一站式自研数据库平台，支持 X86/ARM 混部 想自建数据库平台的企业
轻量版 纯软件输出，跑在客户自己的 IaaS 上 有强自主运维能力的团队

四种形态共享同一套内核，这是 PolarDB 与一些"云上云下两个产品"路线的本质区别------云上验证过的特性可以直接输出到私有化场景，迁移和运维经验可以复用。

另外值得一提的是，2024 年 9 月 PolarDB 通过了中国信息安全评测中心的"安全可靠测评"，这是政企客户采购的一个关键门槛。

1.3 三大引擎对比

维度 PolarDB MySQL 版 PolarDB PostgreSQL 版 PolarDB-X
兼容生态 MySQL 5.6/5.7/8.0 100% 兼容 PG 11/14/15/17 兼容，Oracle 高度兼容 MySQL 协议，集中式/分布式一体
架构 一写多读（最多15只读）/多写多读 一写多读（16 节点、单节点 88 vCPU） Shared-nothing + 存算分离
数据规模 最大 100TB 最大 100TB PB 级
HTAP IMCI 列存索引（100 倍加速） 支持列存与向量 TiDB 式的 HTAP 不具备，但可搭配 IMCI 思路
适用场景 电商、SaaS、通用 OLTP + 轻分析 去 Oracle、GIS、复杂 SQL 超大并发写入、分库分表替代

观点：选引擎不要看功能列表，看你的瓶颈在哪。写瓶颈在"单主节点"就选 MySQL 版一写多读；写瓶颈在"数据规模必须拆分"才上 PolarDB-X。分布式带来的运维复杂度是实打实的，集中式能解决就别分布式。

二、核心架构解析：从存算分离到三层解耦

2.1 存算分离的原理

传统 MySQL 主从架构的问题在于：计算和存储绑定在每一台机器上。扩容要加机器并复制全量数据，写入要写多份（主库 + 各从库），存储利用率低（为峰值预留容量），故障恢复慢（要恢复整个计算+存储栈）。

PolarDB 的解法是把两者彻底拆开：

  • 计算节点无状态：数据库引擎进程（MySQL/PG）跑在计算节点上，数据不在本地，所以计算节点可以秒级水平扩展、分钟级增删；
  • PolarStore 分布式共享存储：所有计算节点挂载同一份存储，主节点写、只读节点读的是同一份数据，不存在"主从数据同步"这个概念，天然消除了复制延迟的大部分问题；
  • RDMA 网络：计算节点与存储节点之间用 RDMA 高速网络交互，IOPS 延迟控制在 100μs 以内------这个数字意味着存算分离带来的网络开销对应用几乎透明。这是 PolarDB 与早期存算分离方案（如 Aurora 第一代）拉开差距的关键工程点。

一写多读是核心拓扑：1 个主节点（可写）+ 最多 15 个只读节点。主备之间是物理复制（redo log 物理 redo 应用，不是 binlog 逻辑重放），事务日志按事务 ID 分区多线程并行应用（并行复制技术），官方数据是 10 万 TPS 下从库延迟从分钟级压到秒级。主备切换保证 0 数据丢失。

成本上有个关键点：新增只读节点只需支付计算节点费用。存储是共享的，加一个只读节点不用复制一份数据，这和传统主从"加一个从库多买一份存储"是数量级的差别。

PG 版的规格上限：最大 100TB 存储、最多横向扩展 16 个节点、每节点最高 88 vCPU。容灾支持同城三机房、三地五中心。

2.2 架构图

#mermaid-svg-ttQ4r3lPK1T9kV6T{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-ttQ4r3lPK1T9kV6T .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-ttQ4r3lPK1T9kV6T .error-icon{fill:#552222;}#mermaid-svg-ttQ4r3lPK1T9kV6T .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-ttQ4r3lPK1T9kV6T .marker{fill:#333333;stroke:#333333;}#mermaid-svg-ttQ4r3lPK1T9kV6T .marker.cross{stroke:#333333;}#mermaid-svg-ttQ4r3lPK1T9kV6T svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-ttQ4r3lPK1T9kV6T p{margin:0;}#mermaid-svg-ttQ4r3lPK1T9kV6T .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-ttQ4r3lPK1T9kV6T .cluster-label text{fill:#333;}#mermaid-svg-ttQ4r3lPK1T9kV6T .cluster-label span{color:#333;}#mermaid-svg-ttQ4r3lPK1T9kV6T .cluster-label span p{background-color:transparent;}#mermaid-svg-ttQ4r3lPK1T9kV6T .label text,#mermaid-svg-ttQ4r3lPK1T9kV6T span{fill:#333;color:#333;}#mermaid-svg-ttQ4r3lPK1T9kV6T .node rect,#mermaid-svg-ttQ4r3lPK1T9kV6T .node circle,#mermaid-svg-ttQ4r3lPK1T9kV6T .node ellipse,#mermaid-svg-ttQ4r3lPK1T9kV6T .node polygon,#mermaid-svg-ttQ4r3lPK1T9kV6T .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-ttQ4r3lPK1T9kV6T .rough-node .label text,#mermaid-svg-ttQ4r3lPK1T9kV6T .node .label text,#mermaid-svg-ttQ4r3lPK1T9kV6T .image-shape .label,#mermaid-svg-ttQ4r3lPK1T9kV6T .icon-shape .label{text-anchor:middle;}#mermaid-svg-ttQ4r3lPK1T9kV6T .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-ttQ4r3lPK1T9kV6T .rough-node .label,#mermaid-svg-ttQ4r3lPK1T9kV6T .node .label,#mermaid-svg-ttQ4r3lPK1T9kV6T .image-shape .label,#mermaid-svg-ttQ4r3lPK1T9kV6T .icon-shape .label{text-align:center;}#mermaid-svg-ttQ4r3lPK1T9kV6T .node.clickable{cursor:pointer;}#mermaid-svg-ttQ4r3lPK1T9kV6T .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-ttQ4r3lPK1T9kV6T .arrowheadPath{fill:#333333;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-ttQ4r3lPK1T9kV6T .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ttQ4r3lPK1T9kV6T .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-ttQ4r3lPK1T9kV6T .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ttQ4r3lPK1T9kV6T .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-ttQ4r3lPK1T9kV6T .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-ttQ4r3lPK1T9kV6T .cluster text{fill:#333;}#mermaid-svg-ttQ4r3lPK1T9kV6T .cluster span{color:#333;}#mermaid-svg-ttQ4r3lPK1T9kV6T div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-ttQ4r3lPK1T9kV6T .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-ttQ4r3lPK1T9kV6T rect.text{fill:none;stroke-width:0;}#mermaid-svg-ttQ4r3lPK1T9kV6T .icon-shape,#mermaid-svg-ttQ4r3lPK1T9kV6T .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-ttQ4r3lPK1T9kV6T .icon-shape p,#mermaid-svg-ttQ4r3lPK1T9kV6T .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-ttQ4r3lPK1T9kV6T .icon-shape .label rect,#mermaid-svg-ttQ4r3lPK1T9kV6T .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-ttQ4r3lPK1T9kV6T .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-ttQ4r3lPK1T9kV6T .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-ttQ4r3lPK1T9kV6T :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 物理复制

并行应用
物理复制
物理复制
RDMA 网络

IOPS 延迟 100μs 内
应用层

Java / Python / Go
PolarProxy 集群地址

自动读写分离
主节点 RW

可读可写
只读节点 RO1

负载均衡
只读节点 RO2
只读节点 RO-N

最多 15 个
PolarStore 分布式共享存储

一份数据 多节点挂载
存储节点集群

三副本强一致

图里有一条容易被忽略的暗线：只读节点之间没有互相复制，它们都从共享存储读数据。这就是"加只读节点不加存储费用"的架构根源。

2.3 三层解耦：CXL 内存池化

2025 年 9 月，阿里云发布了全球首款基于 CXL 2.0 Switch 的 PolarDB 专用服务器，实现了计算-内存-存储的三层解耦。

这是存算分离的下一步。传统服务器里 CPU 和内存绑定在同一块主板上，内存利用率取决于单机负载------内存池化之前，数据库集群的内存利用率往往不到 50%（有的节点内存吃紧，有的节点大量闲置）。CXL 2.0 Switch 把内存变成可池化调度的资源，内存按需分配给计算节点。
#mermaid-svg-jTc9GOn26u8zsWGg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-jTc9GOn26u8zsWGg .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-jTc9GOn26u8zsWGg .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-jTc9GOn26u8zsWGg .error-icon{fill:#552222;}#mermaid-svg-jTc9GOn26u8zsWGg .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-jTc9GOn26u8zsWGg .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-jTc9GOn26u8zsWGg .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-jTc9GOn26u8zsWGg .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-jTc9GOn26u8zsWGg .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-jTc9GOn26u8zsWGg .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-jTc9GOn26u8zsWGg .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-jTc9GOn26u8zsWGg .marker{fill:#333333;stroke:#333333;}#mermaid-svg-jTc9GOn26u8zsWGg .marker.cross{stroke:#333333;}#mermaid-svg-jTc9GOn26u8zsWGg svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-jTc9GOn26u8zsWGg p{margin:0;}#mermaid-svg-jTc9GOn26u8zsWGg .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-jTc9GOn26u8zsWGg .cluster-label text{fill:#333;}#mermaid-svg-jTc9GOn26u8zsWGg .cluster-label span{color:#333;}#mermaid-svg-jTc9GOn26u8zsWGg .cluster-label span p{background-color:transparent;}#mermaid-svg-jTc9GOn26u8zsWGg .label text,#mermaid-svg-jTc9GOn26u8zsWGg span{fill:#333;color:#333;}#mermaid-svg-jTc9GOn26u8zsWGg .node rect,#mermaid-svg-jTc9GOn26u8zsWGg .node circle,#mermaid-svg-jTc9GOn26u8zsWGg .node ellipse,#mermaid-svg-jTc9GOn26u8zsWGg .node polygon,#mermaid-svg-jTc9GOn26u8zsWGg .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-jTc9GOn26u8zsWGg .rough-node .label text,#mermaid-svg-jTc9GOn26u8zsWGg .node .label text,#mermaid-svg-jTc9GOn26u8zsWGg .image-shape .label,#mermaid-svg-jTc9GOn26u8zsWGg .icon-shape .label{text-anchor:middle;}#mermaid-svg-jTc9GOn26u8zsWGg .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-jTc9GOn26u8zsWGg .rough-node .label,#mermaid-svg-jTc9GOn26u8zsWGg .node .label,#mermaid-svg-jTc9GOn26u8zsWGg .image-shape .label,#mermaid-svg-jTc9GOn26u8zsWGg .icon-shape .label{text-align:center;}#mermaid-svg-jTc9GOn26u8zsWGg .node.clickable{cursor:pointer;}#mermaid-svg-jTc9GOn26u8zsWGg .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-jTc9GOn26u8zsWGg .arrowheadPath{fill:#333333;}#mermaid-svg-jTc9GOn26u8zsWGg .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-jTc9GOn26u8zsWGg .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-jTc9GOn26u8zsWGg .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-jTc9GOn26u8zsWGg .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-jTc9GOn26u8zsWGg .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-jTc9GOn26u8zsWGg .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-jTc9GOn26u8zsWGg .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-jTc9GOn26u8zsWGg .cluster text{fill:#333;}#mermaid-svg-jTc9GOn26u8zsWGg .cluster span{color:#333;}#mermaid-svg-jTc9GOn26u8zsWGg div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-jTc9GOn26u8zsWGg .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-jTc9GOn26u8zsWGg rect.text{fill:none;stroke-width:0;}#mermaid-svg-jTc9GOn26u8zsWGg .icon-shape,#mermaid-svg-jTc9GOn26u8zsWGg .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-jTc9GOn26u8zsWGg .icon-shape p,#mermaid-svg-jTc9GOn26u8zsWGg .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-jTc9GOn26u8zsWGg .icon-shape .label rect,#mermaid-svg-jTc9GOn26u8zsWGg .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-jTc9GOn26u8zsWGg .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-jTc9GOn26u8zsWGg .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-jTc9GOn26u8zsWGg :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 2017 前的主流
2025.09 全球首发
第三代：三层解耦（CXL 2.0 专用服务器）
计算池

CPU 无状态
CXL 2.0 Switch

内存池化共享
存储池

PolarStore
第二代：存算分离（PolarDB 经典架构）
计算+内存绑定
存储独立池化

PolarStore
第一代：单机一体化（传统 MySQL）
计算+内存+存储

绑定在同一台服务器

观点：内存池化的价值不只是省内存钱。对数据库来说，Buffer Pool 的大小直接决定缓存命中率，内存池化让"热点节点临时获得大内存"成为可能，这对 HTAP 场景（分析查询需要大量内存做 hash join）和 AI 场景（KVCache 调度）都是地基性能力。这也是为什么 AI Lakebase 建立在三层解耦之上------两者不是巧合，是依赖关系。

2.4 与传统架构对比

维度 单机 MySQL 传统主从架构 PolarDB 存算分离
扩容方式 垂直升级，停机 加从库，需全量复制数据 只读节点分钟级添加，只付计算费
弹性速度 天级 小时级（含数据同步） 秒级（Serverless）/分钟级（加节点）
数据一致性 单机 ACID 异步复制，主备切换可能丢数据 共享存储 + 物理复制，切换 0 丢失
存储利用率 低（单机预留峰值） 低（每从库一份全量） 高（一份数据多节点共享，按用量付费）
复制延迟 无 binlog 逻辑复制，高负载下分钟级 并行物理复制，10 万 TPS 下秒级
故障恢复 慢（恢复计算+存储） 中等（提升从库为主库） 快（计算节点无状态，重挂存储即可）
成本模型 买机器 买 N 台机器 计算 + 存储分离计费，按实际用量

三、Serverless 弹性实战：秒级伸缩与成本优化

3.1 Serverless 的原理与边界

PolarDB Serverless 的核心机制：数据库集群的 CPU 和内存按负载自动扩缩容，伸缩单位是秒级，0 流量时 0 费用。它的底层依赖正是第二章讲的三层解耦------因为计算无状态、内存池化，扩缩容才不需要搬数据，才能做到秒级。

和 Aurora Serverless v2 对比（第三方实测参考数据）：

维度 PolarDB Serverless Aurora Serverless v2
弹性响应 秒级 分钟级
冷启动 约 1 秒 约 5 秒
0 流量计费 0 费用 仍有 ACU 保底计费逻辑
3 年 TCO 低 30-40%（相对 Aurora） 基准

观点：Serverless 不是银弹。它的计费模型本质是"为波动的峰值付了保险费"------负载平稳的应用按量付费可能比包年包月贵。我的判断标准：负载波动超过 3 倍（典型如电商大促、游戏开服、测试环境）用 Serverless；负载平稳的生产核心库用包年包月更省。这是很多"上云省钱"文章不会告诉你的。

3.2 成本优化三板斧

PolarDB 官方宣传的降本路径有三层，我按实战中的收益从大到小排：

第一板斧：智能冷热数据分层（DLM）。业务库里 80% 的数据是冷的（历史订单、过期日志），但传统方案它们占着热存储。DLM 自动把冷数据转到低频存储层。官方数据：100TB 场景下存储月费从 8.2 万降到 3 万+，整体月度成本压到 7-9 万（自建方案 27 万起步）。这是三招里对存量用户收益最大、实施最简单的一招。

第二板斧：Serverless 秒级弹性。前面讲过了，对波动型负载收益明显。GoTo Group 的 GoPay Later 就是典型：按需弹性后云资源消耗降低 50%。

第三板斧：CXL 内存池化。目前主要在专用服务器形态上生效，公有云用户间接受益（同规格性能更高）。这条对采购决策者有意义，对开发者暂时无感。

3.3 Serverless 配置示例

yaml 复制代码 
# PolarDB MySQL 版 Serverless 集群核心参数示意（以控制台实际值为准）
serverless_config:
  # 扩缩容范围：单节点 Resource Unit 的下限与上限（单位 PCU，PolarDB Capacity Unit）
  pcu_min: 1          # 最小算力，流量低谷时的保底规格
  pcu_max: 16         # 最大算力，突发流量的天花板
  # 自动暂停：开启后 0 流量持续超过阈值自动暂停，暂停期间不收计算费用
  auto_pause: true
  pause_threshold_seconds: 300   # 无连接持续 5 分钟后暂停
  # 伸缩灵敏度：观察窗口与触发阈值
  scale_up_threshold: "cpu > 70% 持续 5s"    # 秒级扩容触发
  scale_down_cooldown_seconds: 300           # 缩容冷却，避免抖动
  # 只读节点弹性范围：允许自动增删的只读节点数
  ro_nodes_min: 0
  ro_nodes_max: 8

两个实战提醒：第一，pcu_max 不是拍脑袋定的，要按大促压测的峰值 QPS 换算，留 30% 余量；第二，自动暂停只适合测试环境和非核心业务，生产核心库慎开------业务冷启动的 1 秒延迟虽然短，但核心链路上任何一次都可能是事故。

四、HTAP 实战：IMCI 列存索引 100 倍加速

4.1 IMCI 的原理

HTAP（混合事务分析处理）的矛盾在于：行存适合 OLTP（点查、短事务），列存适合 OLAP（聚合扫描、宽表分析），同一份数据两种格式通常要两套系统。传统方案是 MySQL + ClickHouse 之间做 ETL，链路长、延迟高、一致性难保证。

IMCI（In-Memory Column Index，列存索引）的思路是行存与列存深度融合在同一个数据库里：主节点写行存，列存只读节点（或列存索引）通过物理复制同步数据，复杂 SQL 自动路由到列存执行。对应用完全透明------不用改一行代码，不用搭 ETL。

实测数据（官方发布）：10TB 数据的 TPCH Q1，行存执行 187 秒，列存执行 19 秒。某银行案例：智能索引推荐配合 IMCI，复杂查询从 12 秒降到 2.3 秒，CPU 占用降 40%。SaaS 场景更极端：分析 P95 从 4.2 秒到 0.15 秒（第六章的客户案例）。

4.2 SQL 实战

创建列存索引（MySQL 8.0 语法）：

sql 复制代码 
-- 在现有表上创建列存索引，指定全部参与分析的列
-- 某些版本/形态下使用 CLUSTERED COLUMN 关键字创建聚簇列存索引
ALTER TABLE orders ADD CLUSTERED COLUMN INDEX idx_cci_orders (
    order_id, user_id, shop_id, amount, status, created_at
);

查询时可以显式控制是否走列存：

sql 复制代码 
-- 方式一：默认自动路由，优化器根据成本判断是否走 IMCI
SELECT shop_id, SUM(amount), COUNT(*)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY shop_id;

-- 方式二：hint 强制走列存引擎（IMCI）
SELECT /*+ SET_VAR(use_imci_engine=forced) */
       shop_id, SUM(amount), COUNT(*)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY shop_id;

-- 方式三：hint 强制不走列存（排障时用）
SELECT /*+ SET_VAR(use_imci_engine=off) */ * FROM orders WHERE order_id = 10001;

行列路由说明 ：use_imci_engine 有三个值------off（强制行存）、forced（强制列存）、默认自动（优化器按成本选择）。实战建议：先跑自动路由，用 EXPLAIN 看执行计划确认是否命中 IMCI；只有自动路由判断失误时才用 hint 干预。全局写死 forced 是常见错误，会把点查也压到列存节点上，性能反而劣化。

观点：IMCI 的正确打开方式是"替代轻中量级的分析负载"。如果你们的分析已经是重 T+1 数仓场景（每天 TB 级跑批），IMCI 不是替代品，它是替代"业务库旁边挂一套 ClickHouse 只为几个实时报表"的方案。判断标准：分析查询的数据量在百 GB 级、时效要求秒到分钟级，IMCI 合适；超过这个范围，老老实实上专业数仓。

五、AI 就绪能力：AI Lakebase 与库内 RAG（2026 新重点）

5.1 AI Lakebase 的"4+1"架构

2026 年 1 月发布的 AI Lakebase 是 PolarDB 的 AI 原生化升级。官方给出的"4+1"核心架构，我按数据流方向拆解：

  • 存储层（Lakebase 湖库一体）：结构化数据（表）、半结构化（JSON/日志）、非结构化（文档、图片、音视频）统一管理，不再需要"数据库管结构化 + 对象存储管文件"的拼装；
  • 元数据层（Zero-ETL 实时闭环）：TB 级元数据的实时管理，数据入库即建立元数据索引，消除传统 RAG 中最脏最累的 ETL 环节；
  • 检索层：向量检索 + 全文检索 + 多模态理解，整合 KVCache、图数据库、向量引擎构建高性能检索框架，兼顾长期记忆与短期记忆调度；
  • 模型层（算子即模型 Model-as-an-Operator） ：把模型调用变成 SQL 算子，PREDICT(MODEL ...) 像调用函数一样调用 embedding 或 LLM，热数据直接转 token，支持 Agent AI 接入；
  • +1 硬件层：CXL 内存池化、存算分离、GPU/CPU 混合调度------这是前三层能跑得动的物理基础。

李飞飞（阿里云数据库负责人）的表述是："数据是燃料，处理能力是引擎，热数据与大模型的结合是通往智能的关键路径。"这句话点出了 AI Lakebase 和"数据库外挂向量库"方案的本质区别：热数据不出库。
#mermaid-svg-9gOAluu1kKpiBsM8{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-9gOAluu1kKpiBsM8 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-9gOAluu1kKpiBsM8 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-9gOAluu1kKpiBsM8 .error-icon{fill:#552222;}#mermaid-svg-9gOAluu1kKpiBsM8 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-9gOAluu1kKpiBsM8 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-9gOAluu1kKpiBsM8 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-9gOAluu1kKpiBsM8 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-9gOAluu1kKpiBsM8 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-9gOAluu1kKpiBsM8 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-9gOAluu1kKpiBsM8 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-9gOAluu1kKpiBsM8 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-9gOAluu1kKpiBsM8 .marker.cross{stroke:#333333;}#mermaid-svg-9gOAluu1kKpiBsM8 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-9gOAluu1kKpiBsM8 p{margin:0;}#mermaid-svg-9gOAluu1kKpiBsM8 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-9gOAluu1kKpiBsM8 .cluster-label text{fill:#333;}#mermaid-svg-9gOAluu1kKpiBsM8 .cluster-label span{color:#333;}#mermaid-svg-9gOAluu1kKpiBsM8 .cluster-label span p{background-color:transparent;}#mermaid-svg-9gOAluu1kKpiBsM8 .label text,#mermaid-svg-9gOAluu1kKpiBsM8 span{fill:#333;color:#333;}#mermaid-svg-9gOAluu1kKpiBsM8 .node rect,#mermaid-svg-9gOAluu1kKpiBsM8 .node circle,#mermaid-svg-9gOAluu1kKpiBsM8 .node ellipse,#mermaid-svg-9gOAluu1kKpiBsM8 .node polygon,#mermaid-svg-9gOAluu1kKpiBsM8 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-9gOAluu1kKpiBsM8 .rough-node .label text,#mermaid-svg-9gOAluu1kKpiBsM8 .node .label text,#mermaid-svg-9gOAluu1kKpiBsM8 .image-shape .label,#mermaid-svg-9gOAluu1kKpiBsM8 .icon-shape .label{text-anchor:middle;}#mermaid-svg-9gOAluu1kKpiBsM8 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-9gOAluu1kKpiBsM8 .rough-node .label,#mermaid-svg-9gOAluu1kKpiBsM8 .node .label,#mermaid-svg-9gOAluu1kKpiBsM8 .image-shape .label,#mermaid-svg-9gOAluu1kKpiBsM8 .icon-shape .label{text-align:center;}#mermaid-svg-9gOAluu1kKpiBsM8 .node.clickable{cursor:pointer;}#mermaid-svg-9gOAluu1kKpiBsM8 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-9gOAluu1kKpiBsM8 .arrowheadPath{fill:#333333;}#mermaid-svg-9gOAluu1kKpiBsM8 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-9gOAluu1kKpiBsM8 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-9gOAluu1kKpiBsM8 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-9gOAluu1kKpiBsM8 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-9gOAluu1kKpiBsM8 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-9gOAluu1kKpiBsM8 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-9gOAluu1kKpiBsM8 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-9gOAluu1kKpiBsM8 .cluster text{fill:#333;}#mermaid-svg-9gOAluu1kKpiBsM8 .cluster span{color:#333;}#mermaid-svg-9gOAluu1kKpiBsM8 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-9gOAluu1kKpiBsM8 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-9gOAluu1kKpiBsM8 rect.text{fill:none;stroke-width:0;}#mermaid-svg-9gOAluu1kKpiBsM8 .icon-shape,#mermaid-svg-9gOAluu1kKpiBsM8 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-9gOAluu1kKpiBsM8 .icon-shape p,#mermaid-svg-9gOAluu1kKpiBsM8 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-9gOAluu1kKpiBsM8 .icon-shape .label rect,#mermaid-svg-9gOAluu1kKpiBsM8 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-9gOAluu1kKpiBsM8 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-9gOAluu1kKpiBsM8 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-9gOAluu1kKpiBsM8 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 支撑
支撑
硬件层：CXL + GPU/CPU 混合调度
CXL 内存池化
GPU/CPU 异构调度
模型层：算子即模型
PREDICT 内嵌推理

Embedding / LLM
Agent AI 接入
检索层：多模态混合检索
向量检索
全文检索
多模态理解
KVCache + 图数据库

长短期记忆调度
元数据层：Zero-ETL 实时闭环
统一元数据索引

TB 级元数据管理
存储层：Lakebase 湖库一体
结构化数据

表 / 行列混合
半结构化

JSON / 日志
非结构化

文档 / 图片 / 音视频

5.2 库内 RAG 实战（PolarDB MySQL 版 + IMCI）

环境要求：PolarDB MySQL 企业版集群，需包含列存节点（IMCI）和 AI 节点，内核版本 8.0.2.2.27 及以上。完整流程：知识库文档上传 OSS → 分块向量化 → 建向量索引 → 检索 → 库内 LLM 生成回答。

第一步：知识库向量化 。官方示例工程包含三个脚本：1_upload_file.py（上传知识库文档到 OSS）、2_vectorization.py（分块向量化 + 建向量索引）、3_rag.py（启动 RAG Web 服务）。核心的向量化是调库内模型完成的：

sql 复制代码 
-- 调用库内 text2vec 模型，对文本做在线向量化
-- polar4ai 语法：predict(model 模型名, select 输入列) 是库内模型推理的标准形态
/*polar4ai*/ SELECT * FROM predict(model _polar4ai_text2vec, SELECT '什么是PolarDB的存算分离架构') with();

第二步：建向量索引并检索 。假设分块向量化后已经建好 vector_index 表（含 file_name、chunk_content、vecs 向量列）：

sql 复制代码 
-- 在向量列上建立 IMCI 向量索引（建表后执行）
ALTER TABLE vector_index ADD KEY idx_vec (vecs) WITH (distance_type = cosine);

-- IMCI 向量检索：把用户问题向量化为字符串，用 distance 函数算余弦距离
-- distance(查询向量, 向量列, 'COSINE') 值越小越相似
SELECT /*+ SET_VAR(use_imci_engine=forced) */
       file_name, chunk_content,
       distance(string_to_vector("[0.12, -0.35, 0.87, ...]"), vecs, "COSINE") AS d
FROM vector_index
ORDER BY d
LIMIT 5;

第三步：库内 LLM 生成回答。检索出的 top-k 片段拼进 prompt，直接调库内的通义千问模型：

sql 复制代码 
-- 库内调用通义千问做推理生成，模型推理在数据库节点完成，数据不出域
/*polar4ai*/ SELECT * FROM PREDICT(
    MODEL _polar4ai_tongyi,
    SELECT '基于以下资料回答问题：...（拼接的 top-5 片段）\n\n问题：什么是PolarDB的存算分离架构'
) with ();

实际返回示例（官方演示）：I am a large language model developed by Alibaba Cloud, named Qwen.（耗时 1.64 秒）。整个链路------向量化、检索、重排、生成------全部在数据库内完成。

5.3 库内 RAG 实战（PolarDB PG 版 polar_ai 扩展）

PG 版的路径依赖 polar_ai 扩展，前提是 PostgreSQL 16（内核 2.0.16.10.11.0+）且使用带 GPU 的 AI 节点规格。流程：文档加载 → ai_rag_chunking 分块 → ai_rag_text_embedding 向量化 → HNSW 索引 → 向量相似检索 → ai_rag_rerank 重排 → LLM 生成。

先配置模型 token（以 DashScope 的 embedding 模型为例）：

sql 复制代码 
-- 设置 DashScope 模型调用 token（sk-xxxx 为占位，需替换为实际 token）
SELECT polar_ai.AI_SetModelToken(
    '_dashscope/text_embedding/text_embedding_v2',
    'sk-xxxx'
);

建表、分块、向量化并建 HNSW 索引：

sql 复制代码 
-- 文档分块表：chunk 存文本片段，embedding 存向量
CREATE TABLE t_chunk (
    id serial PRIMARY KEY,
    chunk text,
    embedding vector(1536),
    v tsvector
);

-- 分块结果通过 ai_rag_chunking 生成后，调用库内 embedding 写入
-- 向量化（示意）：更新 embedding 列
UPDATE t_chunk
SET embedding = polar_ai.ai_text_embedding(chunk)::vector(1536);

-- 建 HNSW 向量索引（L2 距离）
CREATE INDEX ON t_chunk USING hnsw (embedding vector_l2_ops);

-- 建 jieba 分词全文索引（rum），用于 sparse 检索
UPDATE t_chunk SET v = to_tsvector('jiebacfg', chunk);
CREATE INDEX ON t_chunk USING rum (v rum_tsvector_ops);

混合检索（dense + sparse）：

sql 复制代码 
-- 密集向量检索：按向量相似度取 top-5
SELECT chunk,
       embedding polar_ai.ai_text_embedding('PolarDB 的主备切换为什么能做到 0 数据丢失')::vector(1536) AS dist
FROM t_chunk
ORDER BY dist ASC
LIMIT 5;

-- 稀疏全文检索：jieba 分词 + rum 索引
SELECT chunk, v
FROM t_chunk
WHERE v @@ to_tsquery('jiebacfg', '存算 & 分离')
LIMIT 5;

-- 两路结果合并后调用 ai_rag_rerank 重排，再交给 LLM 生成

PG 开源教程里的最小向量化示例（不依赖 polar_ai，用开源 pgvector）：

sql 复制代码 
-- 开源 pgvector 最小示例：建表、建 HNSW 索引（余弦距离）
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE tbl_kn_vec (
    id serial PRIMARY KEY,
    vec vector(1536),
    content text
);
CREATE INDEX ON tbl_kn_vec USING hnsw (vec vector_cosine_ops);

5.4 传统 RAG vs 库内 RAG

维度 传统 RAG（DB + 独立向量库 + LLM 框架） PolarDB 库内 RAG（AI Lakebase）
组件数 4-5 个：数据库、向量库（Milvus/ES）、ETL、Embedding 服务、编排框架 1 个：数据库内核内置全链路
数据链路 需要持续 ETL 同步，TB 级元数据同步是痛点 Zero-ETL，数据入库即可检索
检索延迟 跨系统网络往返，通常百毫秒级 库内完成，毫秒级
数据合规 数据要出库到向量服务，需额外脱敏方案 全程留在本地域内，模型推理在库内完成
运维复杂度 多套系统版本、容量、监控各自维护 一套数据库的运维
灵活性 向量库可独立扩容、选型自由 依赖 PolarDB 版本与 AI 节点规格

观点 ：库内 RAG 赢的不是性能极限，是工程复杂度和数据合规。如果你的 RAG 数据本身就是结构化业务数据（订单、工单、合同），必须留在数据库里，库内 RAG 是唯一不需要数据出域的方案------这一点在金融、政务、医疗场景是决定性的。反过来，如果你要做的是海量互联网公开语料的通用问答，独立向量库的横向扩展能力更强。我的建议是：业务数据 RAG 用库内，公开语料大规模检索用专业向量库，两者不冲突。

六、迁移实战：RDS MySQL 到 PolarDB 完整流程

6.1 创建集群的关键配置

创建 PolarDB MySQL 版集群时，三个配置必须想清楚：

  1. 引擎版本与源库一致 。源是 5.7 就选 5.7，源是 8.0 就选 8.0。不要在迁移时顺手升级大版本------5.7 和 8.0 在排序规则（utf8mb4_general_ci vs utf8mb4_0900_ai_ci）、权限模型上都有差异，迁移 + 升级一起做，出了问题你分不清是谁的责任。
  2. 主地址 vs 集群地址 。主地址始终指向主节点（适合写入和强一致读）；集群地址是 PolarProxy 提供的逻辑地址，自动做读写分离和负载均衡。业务应用应该接集群地址，这是最常见的配置错误来源。
  3. 白名单第一时间配置。根据我的观察，"连不上"的问题十有八九是白名单或账号权限问题，不是网络问题。创建集群后第一件事就是把应用服务器 IP 段加进白名单。

6.2 命令行连接验证

bash 复制代码 
# 连接 PolarDB 集群（集群地址格式一般为 pc-xxxx.rwlb.rds.aliyuncs.com）
# 注意：-p 与密码之间不能有空格；<HOST> 替换为你的集群地址
mysql -h pc-2***.rwlb.rds.aliyuncs.com -P3306 -upolardb_mysql_user -pPass***233

# 连接后先验证版本与节点角色
SELECT version();
SHOW STATUS LIKE 'Inno_db_cluster%';

6.3 DTS 迁移三步

DTS（数据传输服务）做 RDS MySQL → PolarDB 迁移，核心是迁移类型必须同时勾选三项：

  • 结构迁移：表、索引、视图等对象定义；
  • 全量数据迁移：存量数据；
  • 增量数据迁移：迁移期间源库的新增写入，通过 binlog 持续同步。

为什么三项必须同时勾选？只做全量的话，全量迁移到切换的窗口期内源库的新写入会丢，业务不能接受。三项齐备才是"不停机迁移"的正确姿势。

bash 复制代码 
# DTS 迁移类型配置要点（控制台操作，此处为核对清单）
# 1. 源库：RDS MySQL 实例，DTS 会自动加白名单（云实例场景免手工配置）
# 2. 目标库：PolarDB MySQL 版集群
# 3. 迁移类型：结构迁移 + 全量数据迁移 + 增量数据迁移（三项全选）
# 4. 源库账号：需要高权限账号（REPLICATION SLAVE 权限用于拉取 binlog）
# 5. 触发器：如源库有触发器，迁移方式需在 DTS 高级配置中显式指定

Online DDL 注意 ：DTS 不支持 pt-online-schema-change 这类工具执行的 Online DDL。如果源库用 gh-ost，它的临时影子表（_表名_gho 格式）需要在 DTS 中配置过滤规则，否则影子表也会被同步过去。

6.4 应用连接示例

Java JDBC：

java 复制代码 
// Java 应用连接 PolarDB 集群地址（自动读写分离）
// <HOST> 替换为集群地址，<DATABASE> 替换为库名
String url = "jdbc:mysql://<HOST>:3306/<DATABASE>"
        + "?useSSL=false&serverTimezone=UTC&rewriteBatchedStatements=true";
Connection conn = DriverManager.getConnection(url, "polardb_mysql_user", "yourPassword");

// 驱动：com.mysql.cj.jdbc.Driver（mysql-connector-j 8.x）
// 建议连接池（HikariCP）最大连接数按只读节点数分摊，写走主节点、读自动路由
PreparedStatement ps = conn.prepareStatement(
    "SELECT order_id, amount FROM orders WHERE user_id = ?");
ps.setLong(1, 10001L);
ResultSet rs = ps.executeQuery();
while (rs.next()) {
    System.out.println(rs.getLong("order_id") + " -> " + rs.getBigDecimal("amount"));
}
conn.close();

Python PyMySQL：

python 复制代码 
# Python 连接 PolarDB 集群地址
# <HOST> 替换为集群地址
import pymysql

conn = pymysql.connect(
    host='<HOST>',      # 集群地址，不要用主地址
    port=3306,
    user='polardb_mysql_user',
    passwd='yourPassword',
    db='your_db',
    charset='utf8mb4',
    cursorclass=pymysql.cursors.DictCursor
)

with conn.cursor() as cur:
    cur.execute("SELECT shop_id, SUM(amount) AS total FROM orders GROUP BY shop_id")
    for row in cur.fetchall():
        print(row)

conn.close()

Go：

go 复制代码 
// Go 连接 PolarDB，使用 go-sql-driver/mysql + database/sql
// <HOST> 替换为集群地址
package main

import (
    "database/sql"
    "fmt"

    _ "github.com/go-sql-driver/mysql"
)

func main() {
    dsn := "polardb_mysql_user:yourPassword@tcp(<HOST>:3306)/your_db?charset=utf8mb4&parseTime=true"
    db, err := sql.Open("mysql", dsn)
    if err != nil {
        panic(err)
    }
    defer db.Close()

    rows, err := db.Query("SELECT order_id, amount FROM orders WHERE user_id = ?", 10001)
    if err != nil {
        panic(err)
    }
    defer rows.Close()

    var id int64
    var amount float64
    for rows.Next() {
        _ = rows.Scan(&id, &amount)
        fmt.Println(id, amount)
    }
}

6.5 切换与回滚要点

  • 切换前用 DTS 的增量同步延迟监控确认延迟低于 1 秒，选业务低峰写停写 → 等增量追平 → 应用改连接串 → 验证 → 恢复写入；
  • 保留源 RDS 只读一周：DTS 支持反向同步（PolarDB → RDS），切换后配置反向同步，一旦新库有问题可以快速回切。这一周是保险期，别急着下线旧库。

6.6 迁移常见坑

坑 现象 解决方案
白名单未配置 应用连不上集群，连接超时 创建集群后第一时间把应用 IP 段加入白名单
用错连接地址 读写分离失效，只读节点空转 业务接集群地址；主地址仅用于写密集或强一致场景
版本选错 排序规则、权限行为与源库不一致报错 引擎版本与源 RDS 严格一致，升级放到迁移完成后单独做
触发器漏迁移 增量数据不一致 源库有触发器时在 DTS 中显式配置迁移方式
gh-ost 影子表被同步 目标库出现 _表名_gho 脏表 DTS 配置库表过滤规则，排除影子表
只做全量迁移 切换窗口期新写入丢失 结构+全量+增量三项必须同时勾选
密码格式问题 命令行登录报错 -p 与密码之间不能有空格

七、横向对比与选型决策

7.1 四大云原生数据库对比

下表来自第三方技术博客实测整理（ITPUB 2026-09），非官方数据，仅供参考：

维度 PolarDB Aurora TDSQL-C TiDB
架构 存算分离（共享存储） 存算分离 存算分离 TiKV 分布式
最大存储 100TB 128TB 32TB 数百TB（需扩容）
计算弹性 秒级 Serverless 分钟级（v2） 分钟级 小时级
MySQL 兼容 100% 99%+ 99%+ 95%
HTAP IMCI 列存（100 倍加速） 无原生列存 无原生列存 TiFlash（10-50 倍）
只读节点 最大 15 个 15 个 10 个 独立 Server
3 年 TCO（16C64G） 约 45 万 约 73 万 约 52 万 约 65 万

几个解读：

  1. MySQL 兼容性差距不是数字游戏。TiDB 的 95% 意味着金融类应用的核心 SQL 大概率要改造，复杂事务、特定隔离级别行为都有差异。从 MySQL 平迁的场景，100% 兼容就是零改造。
  2. HTAP 是 PolarDB 和 TiDB 的独有牌。Aurora 和 TDSQL-C 本质是纯 OLTP 产品，分析要外挂。
  3. TCO 差距在存储和弹性。PolarDB 的 45 万优势来自共享存储（加只读节点不加存储费）和 Serverless 按量计费。

7.2 选型决策要点

决策逻辑比决策结论重要，我给四条判断依据：

  • 国内业务为主、重 MySQL 生态 → PolarDB。兼容性零成本、本地化服务、合规认证齐全；
  • 全球多区部署、AWS 生态绑定 → Aurora。Global Database 跨区复制成熟，但注意其 HTAP 能力缺失、Serverless 冷启动较慢；
  • 必须开源自建、数据规模 PB 级 → TiDB。开源协议友好、水平扩展无上限，代价是兼容性改造和运维投入；
  • 腾讯云生态内 → TDSQL-C。与腾讯云生态集成深，但注意 32TB 存储上限对部分业务是硬约束。

再说什么时候不该选 PolarDB，这是选型文章更该讲清楚的：

  • 强依赖 AWS 全球基础设施的出海业务，PolarDB 的海外 Region 覆盖不如 Aurora；
  • 需要数据库之外的高级能力（如 change data capture 生态、特殊存储引擎插件）且极度依赖开源社区的自定义路线，商业内核的定制自由度低于自建；
  • 单表数据不到 50GB、QPS 峰值不到 1000 的小业务，一台上万元的 RDS 高可用版就够，云原生架构的成本优势体现不出来。

7.3 客户案例数据

  • SaaS 厂商 Aurora → PolarDB：月费 12.8 万降到 7.9 万（-38%），扩容从 8-12 分钟到秒级，分析查询 P95 从 4.2 秒到 0.15 秒（-96%），运维人力从 3 人减到 1 人；
  • AI 客服 SaaS TDSQL-C → PolarDB PG 版：月费 9.6 万降到 6.8 万（-29%），单集群支撑租户从 800 个提升到 3000+，报表 P95 从 5.8 秒到 0.25 秒；
  • Atlas（新加坡航旅平台）：每日 10 亿次航班检索，基础设施成本降 30%，库内模型推理实现毫秒级报价预测；
  • GoTo Group GoPay Later：Serverless 按需弹性，云资源消耗降 50%。

观点：这些案例数据是厂商侧口径，实际收益高度依赖业务负载形态------波动型负载的弹性收益会被放大，平稳型负载可能只有存储分层那一档的收益。对比数据仅供参考，选型前请用自己的真实 SQL 和数据量做 POC 验证。

八、踩坑记录与最佳实践

以下问题来自实际迁移和运维经验，每一条都值得在方案评审时过一遍：

1. 连接地址选错，读写分离形同虚设。 最常见的翻车：应用直接连主地址（始终指向主节点），买了 5 个只读节点结果全部空转。正确做法是业务统一接集群地址，由 PolarProxy 自动路由；写密集或需要强一致读的接口才显式走主地址。

2. 只读节点延迟的认知偏差。 物理复制 + 并行复制把延迟压到毫秒级，但毫秒级不等于零。写后立刻读的场景（下单后马上查订单详情）如果读到从库，可能读到旧数据。原则：要求强一致的读必须 happening 读主，具体做法是走主地址，或使用支持会话一致性读的集群地址特性。别相信"物理复制没延迟"这种说法。

3. Serverless 的适用边界。 前面说过，负载平稳的应用用 Serverless 可能更贵。判断标准看负载峰谷比：3 倍以上波动用 Serverless，平稳负载用包年包月。另外自动暂停功能只适合测试环境。

4. IMCI 不是万能加速器。 不是所有 SQL 都能走列存------高度选择性的点查、小结果集查询走列存反而更慢（列存的强项是大扫描、大聚合）。每次上了 IMCI 都要用 EXPLAIN 验证执行计划确实命中列存节点，别想当然。

5. 向量检索的规模上限。 PolarDB 的 HNSW/IMCI 向量检索在亿级向量以内表现良好，但数据量到十亿级、QPS 要求极高时，应该配合 Tair（缓存层加速）或专业向量库做分层检索。数据库内向量检索的定位是"业务数据 RAG"，不是"通用海量向量服务"。

6. 版本升级与参数兼容。 5.7 升 8.0 有两个经典雷区：排序规则从 utf8mb4_general_ci 系切到 utf8mb4_0900_ai_ci 系，会导致索引行为和比较结果差异；权限模型从 mysql.user 表直接操作变为 CREATE USER/GRANT 体系。迁移时版本严格对齐，升级单独规划窗口单独回归测试。

7. 迁移前压测必须用真实流量回放。 用 SELECT 1 测连通性通过了不等于能用。真实 SQL 回放（DAS 支持从源库抓取慢 SQL 回放）是唯一能暴露执行计划差异的手段。

九、总结与展望

回顾全文的核心判断：

  • 存算分离是云原生数据库的基座。计算无状态 + PolarStore 共享存储 + RDMA 低延迟网络，解决了传统主从架构的弹性、一致性、成本三座大山，这是 PolarDB 一切能力的地基；
  • Serverless 是成本解法，但有适用边界。秒级弹性、0 流量 0 费用对波动型负载是实质收益，平稳负载请老实用包年包月；
  • IMCI 把 HTAP 的门槛从"维护两套系统"降到"加一个列存索引"，是存量 MySQL 用户最容易落地、见效最快的特性；
  • AI Lakebase 是下一站。"4+1"架构把湖库一体、Zero-ETL、多模态检索、算子即模型收进数据库内核，库内 RAG 解决的是工程复杂度和数据合规两个真问题。

往后看，AI 原生数据库的趋势已经清晰：热数据与大模型的直接结合（热数据转 token）、Agent 的长短期记忆调度、CXL 硬件层的异构算力调度，会让数据库从"存数据"进化为"供燃料"。李飞飞说的"数据是燃料，处理能力是引擎"，在 AI Lakebase 的架构里已经能看到雏形。

对开发者的建议：存量 MySQL/PG 用户，现在就可以开始评估存算分离的迁移收益（存储分层 + 只读节点成本模型）；有 RAG 需求的团队，优先试库内 RAG 的 POC，把"数据不出域"作为架构约束来审视现有方案。

参考资料

  1. PolarDB 产品官方主页 - 阿里云
  2. PolarDB MySQL 版官方文档 - 阿里云
  3. PolarDB 开源项目 - GitHub / Gitee
  4. PolarDB PostgreSQL 版 polar_ai 扩展与 RAG 实战文档
  5. TPC-C 基准测试结果公告 - TPC 官网
  6. Gartner 云数据库管理系统魔力象限（2025.12）
  7. 阿里云 AI Lakebase 发布公告（2026.01）- 阿里云
  8. 四大云原生数据库对比实测 - ITPUB 技术博客（2026-09，第三方参考）
  9. DTS 数据迁移最佳实践 - 阿里云文档
相关推荐
hzxpaipai1 小时前
AI把网站页面做出来了，谁来负责后台、服务器和正式上线？
运维·服务器·人工智能
牧羊人.3331 小时前
动手学深度学习 06|学习率调整
人工智能·深度学习·学习
四六的六1 小时前
GPT-6 会自己画界面了：从写页面到定规则，前端在 Intelligent UI 时代的新活法
人工智能·个人开发·ai编程·ai大模型·组件库·ai产品·ui界面
我不会起名字3221 小时前
InnoDB 间隙锁与死锁：两个 UPDATE 互相等待的 3 个原因
数据库·mysql·事务·innodb·锁
承渊政道1 小时前
【从零开始大模型开发与微调:基于PyTorch与ChatGLM】(开源大模型ChatGLM使用详解)
人工智能·pytorch·开源·llm·chatglm
ClickHouseDB1 小时前
ClickHouse Terraform Provider 正式支持 ClickStack 资源管理
网络·数据库·python
ToddyBear1 小时前
从 Pod 编排到数据互联：基于 K8s 与 Snowflake 打造下一代异构查询桥梁实践
云原生·容器·kubernetes
步行cgn1 小时前
Spring 事务属性详解
java·数据库·spring
loulanyue_1 小时前
Qwen Intelligence手机智能底座：读阿里副总裁许主洪2026云栖演讲
人工智能·智能手机·移动端
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03历年考研数学一、数学二、数学三真题试卷及答案PDF04GitHub 镜像站点05蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接06Telegram APK 下载安装完整指南 — 2026年最新07微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新08Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）09轻量化AI渗透武器库｜ARTEX自主攻防系统、资产梳理、漏洞挖掘、链路分析全流程智能化落地102026 爱知・名古屋亚运会怎么看？直播平台+赛程安排分享