一、快速选型图谱（一句话定位）
OLTP（强事务/行存）：MySQL、PolarDB（云原生版MySQL/PG/Oracle 兼容）。MySQL 开发者专区Alibaba Cloud
分布式 OLTP/弹性扩展（MySQL 兼容）：PolarDB-X、TiDB（同时具备 HTAP 能力）。Alibaba Cloud+1PingCAP 文档
文档/半结构化：MongoDB（天然 JSON 文档模型，易开发、易水平扩展）。MongoDB
宽表/时序/超大吞吐的 Serverless 存储服务：TableStore（毫秒级查询，面向 IoT/IM 等）。Alibaba Cloud+1
OLAP/列存/超快聚合分析：ClickHouse（亚秒级分析查询）。ClickHouse+1
二、产品对比（技术特性 × 适配场景）
1) MySQL（单体/主从/读写分离的事实标准）
核心特性：关系型、ACID 事务、InnoDB 行存、二进制日志复制；成熟生态、成本低；水平扩展需应用侧分片或引入分布式中间层。适合 90% 常规 OLTP。MySQL 开发者专区
适配场景：交易、订单、库存、会员、账务等中小体量核心库；对可靠事务一致性有要求的传统业务。
不适用：单库数据/吞吐增长到“分库分表”的临界点后，治理成本快速上升。
上手要点：读写分离、连接池、慢 SQL 优化、合适的二级索引设计、备份/主从延迟监控。
官方文档：MySQL 8.x 参考手册。MySQL 开发者专区
2) PolarDB（阿里云云原生 RDS“增强型”）
定位：计算存储分离、秒级弹性、MySQL/PG/Oracle 兼容；读写扩展、HA、共享分布式存储。适合云上 OLTP/读多写少读写分离。Alibaba Cloud+1
适配场景：上云后需要弹性扩容、只读节点横向扩展、金融级高可用；与 MySQL/PG 生态无缝兼容的改造最小方案。
不适用：需要“应用透明的跨分片写扩展”的极限水平扩展（用 PolarDB-X/TiDB 更合适）。
实践要点：合理使用只读节点、存算分离的扩缩容窗口；配合全局事务需求时需评估分布式方案（与 PolarDB-X 的组合）。
文档：产品综述与入门。Alibaba Cloud
3) PolarDB-X（阿里云分布式 MySQL 兼容数据库）
定位：云原生分布式、MySQL 语法兼容、跨分片全局二级索引、分布式事务（TSO + 分布式 MVCC）、X-Paxos 容灾，面向海量数据 & 超高并发，具备 HTAP 能力。Alibaba Cloud+1
适配场景：电商大促（海量订单/交易）、会员/商品等大表写入与查询并发极高、单表亿级/十亿级且需应用“低侵入”扩展。
不适用：对专门的列存 OLAP 深度分析（复杂聚合/向量化）单看性价比依旧不如 ClickHouse。
实践要点：
合理分库分表键、热点 Key 治理；跨分片 JOIN/事务尽量避免；写入/查询路由（Hint）优化。
利用 HTAP 能力分流轻量分析；评估全局二级索引的写放大成本。
文档：架构与特性/场景综述。Alibaba Cloud+1
4) TableStore（阿里云表格存储 Tablestore）
定位：Serverless 表服务，宽表/时序/多维模型，毫秒级在线查询、高吞吐、低成本，适合 IoT/IM/车联网/风控画像等。支持时序存储、索引与多维分析集成。Alibaba Cloud+1
适配场景：
IoT/车联网：海量设备上报（写入吞吐高、单条价值低、冷热明显）。
IM/日志/埋点：流水式写入、基于主键与时间的快速检索。
不适用：强事务多表 JOIN 的传统 OLTP（它不是关系型数据库）。
实践要点：主键设计（热点分散）、TTL/多版本、时序索引与分析通道（如数据下沉到湖仓/OLAP）。
文档：产品概述、功能与场景。Alibaba Cloud+1
5) MongoDB（文档型数据库）
定位：BSON 文档、灵活 Schema、天然分片（Shard）、副本集 HA；支持事务（近年支持多文档事务），开发效率高，JSON 生态友好。MongoDB
适配场景：内容/社交/画像配置/活动规则/非严格结构的聚合查询；快速迭代、模型频繁演进。
不适用：强关系、多表事务严苛一致性（虽然有事务，但代价与生态不如成熟 RDBMS）。
实践要点：
设计文档内聚（嵌入 vs 引用）与合适的分片键；
读写 Concern/事务成本评估；
TTL、复合索引、聚合管道性能调优。
文档：官方手册与安装指南。MongoDB+1
6) TiDB（开源分布式 SQL，MySQL 兼容，HTAP）
定位：SQL 层（TiDB Server）+ 存储层 TiKV（分布式 KV, Raft 复制）+ PD（TSO 时间戳服务）；分布式事务 + MVCC；配套 TiFlash 列存 实现 HTAP。PingCAP 文档+2PingCAP 文档+2
适配场景：
水平扩展的 OLTP（交易、订单、金服风控等）；
同库轻量实时分析（HTAP：在线数据一份多引擎）。
不适用：极致的离线重型数仓（复杂多表分析仍建议专用 OLAP/湖仓）。
实践要点：合理表/索引设计，尽量避免全局热点；
PD/TSO 与 Region 调度监控；
对分析型负载启用 TiFlash 副本，分流查询。
文档：架构/开发者指南/FAQ。PingCAP 文档+2PingCAP 文档+2
7) ClickHouse（列式 OLAP）
定位：列式存储 + 向量化执行，极致聚合/扫描速度，适合实时/准实时分析、事件明细查询、报表与看板；SQL 接口，生态丰富。ClickHouse+1
适配场景：日志/埋点/广告点击流/监控时序/用户画像明细分析、A/B 实验、报表 KPI。
不适用：强事务 OLTP（频繁小事务写入与强一致更新）。
实践要点：
表引擎（MergeTree 家族）选择、分区/主键/采样键设计；
批量写入、分区冷热分层；
物化视图/汇总表提升查询。
文档：产品与入门。ClickHouse+1
关键维度对比（浓缩版）
| 维度 | MySQL | PolarDB | PolarDB-X | TableStore | MongoDB | TiDB | ClickHouse |
|---|---|---|---|---|---|---|---|
| 数据模型 | 关系/行存 | 关系/行存（云原生） | 关系/行存（分布式） | 宽表/时序/NoSQL | 文档/BSON | 关系/行+列（TiFlash） | 列存/OLAP |
| 事务与一致性 | 单机 ACID | ACID，云上 HA 弹性 | 分布式事务（TSO/MVCC） | 无传统多表事务 | 单/多文档事务 | 分布式事务（TSO/MVCC） | 弱事务（分析为主） |
| 扩展性 | 垂直/读写分离 | 存算分离，读扩展 | 水平线性扩展 | Serverless 水平扩展 | 分片水平扩展 | 水平线性扩展 | 水平扩展（分析） |
| 典型场景 | 经典 OLTP | 云上 OLTP/读多写少 | 大促/亿级大表 OLTP | IoT/IM/日志 | 半结构化业务 | HTAP/分布式 OLTP | 实时/准实时分析 |
| 生态兼容 | 强 | MySQL/PG/Oracle 兼容 | MySQL 兼容 | SDK/生态组件 | 广泛驱动/工具 | MySQL 兼容 | SQL/驱动丰富 |
（PolarDB/PolarDB-X、TiDB 的分布式事务、HTAP、存算分离/列存等定位，详见各官方总览与架构文档。Alibaba Cloud+2Alibaba Cloud+2PingCAP 文档）
三、典型业务场景选型建议（含落地提示）
电商交易/订单/库存
体量可控：MySQL 或 PolarDB（读写分离 + 主从容灾）。
高并发/海量：PolarDB-X 或 TiDB（分库分表透明化 + 分布式事务 + 扩容平滑）。
若报表/画像也要跑在同库：TiDB + TiFlash（HTAP）。PingCAP 文档
用户画像/行为明细 + 实时看板
明细落盘：ClickHouse（高压缩 + 快扫 + 物化视图）；
若生产系统即 MySQL/PolarDB/TiDB，可用 CDC/流式同步到 ClickHouse 做分析面。ClickHouse
IoT/车联网/IM（高吞吐、低成本、毫秒级查询）
TableStore 为主存（Serverless、时序/宽表），必要时汇总或下沉到 ClickHouse/湖仓。Alibaba Cloud+1
内容/社交/活动配置/动态 Schema
MongoDB（文档内聚、聚合管道）；对强事务的子域仍建议 RDBMS。MongoDB
金融级 HA + 云上弹性
PolarDB（多只读节点、秒级弹性），或 PolarDB-X/TiDB 做分布式主库。Alibaba Cloud
迁移与兼容注意：PolarDB-X、TiDB 均兼容 MySQL 协议/语法，但跨分片事务/Join/函数、序列、自增、时间语义等需要回归测试与 SQL 治理。Alibaba CloudPingCAP 文档
四、上手与操作手册（官方文档/快速实践）
MySQL
参考手册（8.x）：安装、SQL、复制、备份恢复。MySQL 开发者专区
PolarDB（阿里云）
产品总览/入门（MySQL/PG/Oracle 兼容、存算分离、弹性/HA）。Alibaba Cloud
PolarDB-X（阿里云分布式 MySQL）
产品页与能力综述（HTAP、超高并发、海量存储）。Alibaba Cloud
体系与协议：X-Paxos、TSO、分布式 MVCC、容灾。Alibaba Cloud
TableStore（表格存储）
什么是 Tablestore & 典型场景（IoT/IM/车联网/风控）。Alibaba Cloud
功能特性与最新更新（毫秒级查询、多维分析、低成本 Serverless）。Alibaba Cloud
MongoDB
TiDB（PingCAP）
稳定版文档（Self-Managed）：特性、部署、开发、运维。PingCAP 文档
架构（TiDB/TiKV/PD、TSO、Raft）与 HTAP（TiFlash）。PingCAP 文档
开发者指南（示例应用/常见问题）。PingCAP 文档
ClickHouse
官方文档与快速开始（安装/表引擎/查询/物化视图）。ClickHouse
“What is ClickHouse?”（OLAP/列存/为何快）。ClickHouse
五、核心术语与技术说明
| 术语 | 定义 | 关键特性 | 典型技术 |
|---|---|---|---|
| OLTP | 联机事务处理 | 高频小事务，低延迟，强一致性 | 行存储、ACID |
| OLAP | 联机分析处理 | 大数据量聚合分析 | 列存储、向量化执行 |
| HTAP | 混合事务与分析处理 | 一套系统同时支持事务与分析 | 双引擎、冷热分离 |
| Serverless | 无服务器架构 | 按需弹性伸缩，按量计费 | 存算分离、自动调度 |
| TSO | 时间戳服务 | 分布式全局事务顺序 | 全局时钟、MVCC |
六. 数据库选型对比
| 数据库 | 类型定位 | OLTP | OLAP | HTAP | Serverless | TSO 支持 | 优势 | 劣势 |
|---|---|---|---|---|---|---|---|---|
| MySQL | 传统关系型 | ✅ 强 | ❌ 弱 | ❌ | 部分（云厂商改造） | ❌ | 成熟稳定、生态丰富、易用 | 扩展性差、分布式弱 |
| PolarDB | 云原生 MySQL/PostgreSQL 兼容 | ✅ 强 | ⚠️ 一般（需配合分析节点） | ❌ | ✅ PolarDB Serverless | ❌ | 云弹性扩容、兼容性好 | 成本随负载变化，分析性能不如专用 OLAP |
| PolarDB-X | 分布式数据库 | ✅ 强（分布式 OLTP） | ⚠️ 一般 | ✅（支持 HTAP） | ⚠️ 半支持 | ✅ | 分布式扩展好，HTAP 能力 | 架构复杂、成本高于单机 |
| TableStore | 全托管多模型（宽表+时序+索引） | ⚠️ 一般（写多读少） | ⚠️ 中（需二次处理） | ❌ | ✅ | ❌ | 超大规模扩展、免运维、Serverless | 不适合复杂事务、SQL 支持弱 |
| MongoDB | 文档型数据库 | ✅ 强（但弱于 RDBMS 一致性） | ❌ 弱 | ❌ | 部分（Atlas Serverless） | ❌ | 灵活 schema、JSON 原生支持 | 跨文档事务弱、复杂分析差 |
| TiDB | 分布式 NewSQL | ✅ 强 | ⚠️ 中（需 TiFlash） | ✅（TiFlash 列存） | ⚠️ 半支持 | ✅ | 强一致分布式事务、HTAP | 对硬件和网络要求高 |
| ClickHouse | 列存分析数据库 | ❌ 弱 | ✅ 强 | ❌ | 部分（ClickHouse Cloud） | ❌ | 极致分析性能、压缩率高 | 不适合高并发事务、更新代价高 |
七. 应用场景推荐
7.1 高并发交易（OLTP）
推荐：MySQL（中小业务）、PolarDB（云弹性）、PolarDB-X（分布式事务）、TiDB（分布式事务）
注意：
核心金融/订单场景建议选择强一致性方案（PolarDB-X / TiDB）
数据量超过单机极限（>5TB 或 QPS>10万）需考虑分布式方案
7.2 大数据分析（OLAP）
推荐：ClickHouse（实时分析）、Doris（BI）、Hive（离线）
注意：
数据导入延迟影响实时性
大量 JOIN/聚合需设计合理的分区键和排序键
7.3 混合型（HTAP）
推荐：TiDB+TiFlash（强一致+实时分析）、PolarDB-X HTAP
注意：
分析负载需隔离，避免影响事务性能
列存副本需要额外存储成本
7.4 弹性负载（Serverless）
推荐：PolarDB Serverless、TableStore
注意：
冷启动延迟对实时性敏感业务不友好
计费模型需监控，避免流量尖峰导致账单高涨
7.5 分布式事务一致性（TSO）
推荐：TiDB（PD 提供 TSO）、PolarDB-X
注意：
TSO 服务单点性能需监控
时钟漂移会影响事务排序，需保证 NTP 精度