云厂商魔改版真相：Aurora / PolarDB / Lindorm / TDSQL

这些"兼容 MySQL/MariaDB"的产品到底改了什么、坑在哪、什么场景该用什么

云厂商喜欢把"MySQL 兼容"印在 marketing 页上。但点开看实际行为，跟上游 MySQL / MariaDB 差异可能很大。这一篇讲清楚。

一句话总结

产品	是什么	与上游
AWS Aurora MySQL	重写存储层的 MySQL	兼容 95%，存储完全不同
AWS Aurora Serverless V2	Aurora + 自动伸缩	同上 + ACU 计费
AWS RDS for MySQL	"纯" MySQL 托管	兼容 99%（小差异）
AWS RDS for MariaDB	"纯" MariaDB 托管	兼容 99%
阿里 PolarDB MySQL	重写存储层的 MySQL	兼容 95%
阿里 PolarDB-X	分布式 SQL	协议兼容，行为不同
阿里 RDS for MySQL	"纯" MySQL	99%
阿里 RDS for MariaDB	"纯" MariaDB	99%（版本旧）
阿里 Lindorm	HBase + SQL 兼容	协议兼容、引擎完全不同
腾讯 TDSQL for MySQL	改 5.7 加分布式	80%（注意）
腾讯 TDSQL-C	类似 Aurora	95%
腾讯 CDB for MySQL	"纯" MySQL	99%
华为 GaussDB(for MySQL)	类似 Aurora	95%
TiDB	自研分布式	协议兼容、SQL 子集
OceanBase	蚂蚁自研分布式	协议兼容
SingleStore	内存 + 列存	协议兼容、引擎完全不同
Doris	OLAP 列存	协议兼容、OLAP only
StarRocks	OLAP 列存 fork of Doris	同上

AWS Aurora MySQL

什么：AWS 把 MySQL InnoDB 存储层换成了分布式存储（6 副本跨 3 AZ），保留 SQL 层。

改了什么：

存储分布式 → 失败自动 failover < 30s
写副本不阻塞主（不像传统复制）
Backtrack 可"时间回退"
Parallel Query 部分大查询自动并行
计费按 IOPS + 实例

没改：SQL、客户端协议、大部分配置项。

坑：

binlog 默认不开，复制要手动启
innodb_buffer_pool_size 自动设，无法手动
某些 storage 相关命令报错（OPTIMIZE TABLE 行为不同）
Aurora 自有函数 aws_* 系列在迁出时要改
Failover 主写从读切换会丢秒级 in-flight 事务（取决于副本同步）

适合：写多读多、跨 AZ 强可用、不在意 vendor lock-in。

不适合：成本敏感、需要完全开源、想用 MariaDB 特性（VECTOR/ColumnStore 等都没有）。

详见从 Aurora 迁移。

Aurora Serverless V2

什么：在 Aurora 之上加自动伸缩。按 ACU（Aurora Capacity Unit）实时计费。

坑：

冷启动有延迟（数据预热）
长事务可能阻止 scale down
没法精细控制实例规格

适合：流量峰谷剧烈、预测困难的场景。否则成本上其实不便宜。

阿里 PolarDB for MySQL

什么：阿里版本的"Aurora"——共享存储 + 多副本。比 RDS 性能更好。

改了：

存储用 PolarFS 分布式文件系统
主从切换秒级
跨地域只读节点
"Cold Backup"自动归档

没改：SQL 层兼容 MySQL 8.0。

坑：

跨地域延迟看物理网络
控制台权限模型与 RDS 不同
备份格式跟 RDS 不通用（迁移要重做）

适合：阿里云生态、性能敏感、能接受 lock-in。

适合代替 RDS for MariaDB？ 通常是——PolarDB MySQL 8.0 兼容性比阿里那古老的 RDS MariaDB 10.5 还更接近主流 MariaDB 11.x 用法。

阿里 PolarDB-X

什么：分布式 SQL，水平分片。

坑：

跨分片 JOIN 慢甚至不支持
事务跨分片用 XA / 2PC，性能差
某些原生 MySQL 函数没实现

适合：单库放不下的超大业务（订单 50 亿+）。

不适合：90% 的业务——单实例 MariaDB / PolarDB 就够。

阿里 Lindorm

什么：基于 HBase + 自研引擎，兼容 MySQL 协议但存储完全不同。

适合：

海量时序数据
宽稀疏表
写多读少

坑：

SQL 子集（不支持完整 SQL）
二级索引限制多
跟 MySQL 客户端配合 90%，但有 SQL 报错时要查 Lindorm 文档而非 MySQL

典型场景：IoT、监控、用户行为日志。

腾讯 TDSQL for MariaDB / MySQL

什么：腾讯魔改版，基于 MariaDB 5.7 / MySQL 5.7 加了分布式 + 强一致改造。

坑：

不是上游 MariaDB。某些 11.x 新功能不支持
文档比腾讯 CDB 少
主推方向是金融场景

适合：金融、银行、强一致跨地域。

不适合：常规 web 业务——用腾讯 CDB MySQL 反而更接近上游。

腾讯 TDSQL-C（Cynos）

什么：腾讯版本的 Aurora。计算存储分离。

坑：类似 Aurora，但小一些。

适合：在腾讯云想要 Aurora-like 体验。

TiDB

什么：PingCAP 出品的分布式 NewSQL，协议兼容 MySQL但完全自研。

特点：

水平扩展无上限
强一致（Raft）
HTAP（行存 TiKV + 列存 TiFlash）
跨地域多活

坑：

单点写入性能不如单机 MySQL/MariaDB
某些 MySQL SQL 不支持（窗口函数有限制等）
部署运维复杂
优化器和 MySQL/MariaDB 不同，老经验不一定适用

适合：

单库放不下、要水平扩展
HTAP（实时分析 + 在线交易）
多活 / 跨地域强一致

OceanBase

什么：蚂蚁自研分布式数据库，Paxos 多副本强一致，协议兼容 MySQL。

适合：金融、超大规模、能接受厂商定价。社区版功能完整。

坑：

MySQL 兼容性逐版本提高，但与上游仍有差异
部署运维门槛高

SingleStore（MemSQL）

什么：内存 + 列存 + 行存混合，协议兼容 MySQL。

特点：内存表行存做 OLTP，列存做 OLAP，单库混合。

适合：超低延迟混合负载、向量检索（强项）。

坑：商业产品，不便宜。

Doris / StarRocks

OLAP only。协议兼容 MySQL 但不能当 OLTP用——单行更新慢、事务弱。

适合：替代 ClickHouse 做实时数仓。

选型决策树

我的诉求是什么？
├─ OLTP，单库容量 < 数 TB
│  ├─ 想用 MariaDB 11.x 新特性 → 自建 / SkySQL
│  ├─ 性能 / 高可用 / 不在乎 lock-in → Aurora / PolarDB / TDSQL-C
│  └─ 想要最接近上游 + 托管 → AWS RDS for MariaDB / 腾讯 CDB
├─ OLTP，单库 > 数 TB
│  ├─ 全球多活 → TiDB / Aurora Global
│  ├─ 金融强一致 → OceanBase / TDSQL
│  └─ 国内简单分片 → PolarDB-X
├─ OLAP / 数仓
│  ├─ 想跟 OLTP 一个 server → MariaDB ColumnStore
│  ├─ 独立数仓 → Doris / StarRocks / ClickHouse
│  └─ 内存级超低延迟 → SingleStore
├─ 时序 / IoT
│  └─ Lindorm / TimescaleDB / TDengine
└─ 向量 RAG
   ├─ 已有 MariaDB 11.8+ → 用原生 VECTOR（见 [RAG with VECTOR](/docs/ai/rag-with-vector)）
   ├─ 想极速 → SingleStore / Qdrant
   └─ 想免运维 → Pinecone

兼容性测试方法

迁过去前，跑：

pt-upgrade source-conn target-conn --queries=production.log

可以对比两端跑同样查询的结果是否一致。

一句话忠告

"MySQL 兼容"≠"能 drop-in 替换"。任何"魔改版"都要测自己业务的关键路径。