背景

我们的系统长期以来采用 MySQL（InnoDB） 作为 OLTP 主库，TiDB 作为分布式扩展层，整体承载了核心业务的读写和部分分析型查询。

然而，近期的外部变化让我们不得不重新审视这套技术选型：

1. 云运营商开始停止维护 MySQL 8.4 以下版本，意味着旧版本将失去安全补丁和官方支持；
2. MySQL 8.4 引入了大量不向前兼容的变更，升级成本极高，部分语法和行为与旧版本存在显著差异；
3. TiDB 宣布在 MySQL 8.4 协议适配上存在严重兼容性问题，无法跟进升级，继续使用意味着与主库协议脱节，维护风险急剧上升。

在综合评估成本、风险与长期可维护性之后，我们决定：

• OLTP 层：MySQL → PostgreSQL
• OLAP / 分布式分析层：TiDB → Apache Doris

本文记录这次迁移的技术背景、差异对比与决策过程，供团队参考与后续回溯。

第一部分：MySQL → PostgreSQL

为什么不选择继续升级 MySQL？

与其在 MySQL 版本升级上消耗大量人力，不如借重构窗口切换到一个更现代、更标准、生态更开放的数据库。

MySQL（InnoDB）vs PostgreSQL 核心差异

1. 存储引擎架构

2. MVCC 实现差异

两者都实现了 MVCC（多版本并发控制），但实现路径不同：

• MySQL InnoDB：旧版本数据存储在 Undo Log 中，主数据文件只保留最新版本，读取旧版本需回溯 Undo 链。
• PostgreSQL：旧版本数据直接存储在数据页中，每行记录 xmin / xmax 事务号标记版本，无需 Undo Log，但需要 VACUUM 定期清除死行，防止表膨胀。

3. 锁机制

注意：PostgreSQL 没有间隙锁，因为其 MVCC 实现本身已经能在 Repeatable Read 级别防止幻读，无需依赖间隙锁。

4. 索引体系

5. SQL 标准兼容性

PostgreSQL 对 SQL 标准的兼容程度显著高于 MySQL，迁移后我们获得了：

-- 窗口函数（MySQL 8.0 才支持，PG 很早就有）
SELECT user_id, amount,
       SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at) AS running_total
FROM orders;

-- CTE（公共表表达式）
WITH ranked AS (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC) AS rn
  FROM products
)
SELECT * FROM ranked WHERE rn <= 3;

-- JSONB 原生支持（比 MySQL JSON 类型更强）
SELECT * FROM events WHERE payload @> '{"type": "login"}';
CREATE INDEX idx_payload ON events USING GIN(payload);

-- 范围类型
SELECT * FROM reservations
WHERE daterange(start_date, end_date) @> '2026-04-07'::date;

6. 事务与一致性

PostgreSQL 支持 DDL 事务 是一个非常重要的运维优势。执行 ALTER TABLE 失败时可以整体回滚，避免数据库处于中间状态。

迁移注意事项

迁移过程中需要重点关注以下差异：

语法层面

• MySQL 的 `反引号` 标识符在 PG 中需改为 "双引号"
• AUTO_INCREMENT 改为 SERIAL 或 GENERATED ALWAYS AS IDENTITY
• LIMIT x, y 改为 LIMIT y OFFSET x
• GROUP BY 在 PG 中更严格，SELECT 的非聚合列必须出现在 GROUP BY 中

行为层面

• PG 字符串比较大小写敏感，MySQL 默认不敏感
• PG 的 boolean 类型是真正的布尔，不是 0/1 整数
• 时间类型处理更严格，需要明确时区

运维层面

• 需要制定 VACUUM 和 ANALYZE 的定期维护策略
• 监控表膨胀（Table Bloat），必要时执行 VACUUM FULL

第二部分：TiDB → Apache Doris

为什么放弃 TiDB？

TiDB 是一款兼容 MySQL 协议的 HTAP 分布式数据库，在 MySQL 5.7 / 8.0 时代为我们提供了良好的水平扩展能力。但随着 MySQL 8.4 的演进，问题开始浮现：

面对这些问题，我们选择将 OLAP 职责交给更专业的引擎——Apache Doris。

TiDB vs Apache Doris 核心差异

Apache Doris 的核心优势

1. 向量化执行引擎

Doris 采用全面向量化的执行引擎，利用 SIMD 指令集对列存数据进行批量计算，在 GROUP BY、JOIN、聚合类查询上性能远超行存数据库。

2. 丰富的数据模型

Duplicate Key Model   → 明细表，保留所有原始数据
Aggregate Key Model   → 预聚合，适合指标汇总
Unique Key Model      → 主键唯一，适合 CDC 场景（Update/Delete）

3. 实时数据接入

Flink → Doris（通过 Doris Flink Connector）
Kafka → Doris（Routine Load）
MySQL Binlog → Doris（通过 Flink CDC）

4. 与 PostgreSQL 协同

在新架构中，PostgreSQL 与 Doris 各司其职：

业务写入 → PostgreSQL（OLTP）
                ↓
         Binlog / CDC 同步
                ↓
         Apache Doris（OLAP）
                ↓
         报表 / 数据分析 / BI 工具

新架构总览

┌─────────────────────────────────────────┐
│              业务应用层                   │
└────────────┬──────────────┬─────────────┘
             │              │
      OLTP写入/读取    分析型查询/报表
             │              │
    ┌────────▼──────┐  ┌────▼──────────┐
    │  PostgreSQL   │  │ Apache Doris  │
    │  (主库 OLTP)  │  │  (OLAP 数仓)  │
    └───────────────┘  └───────────────┘
             │              ▲
             └──── CDC ─────┘
              (Flink / Debezium)

旧架构：MySQL (OLTP) + TiDB (分布式扩展 / HTAP)
新架构：PostgreSQL (OLTP) + Apache Doris (OLAP)

职责更清晰，每层使用最适合的工具。

总结

这次迁移的核心驱动力是外部环境的变化（云厂商 EOL、MySQL 8.4 不兼容），但结果是我们主动拥抱了更好的技术选型：

技术债务的清偿往往需要一个契机