WHAT — Create and maintain Arc…

# 说明

我无法直接操作你们的GitHub仓库（没有仓库访问权限），但我可以完成ADR的全部内容撰写，并给出入库操作步骤。以下内容可直接复制保存为 docs/adr/0001-migrate-order-service-to-tidb.md。

---

# ADR-0001：订单服务存储从 MySQL 迁移至 TiDB

状态：已接受（Accepted）

日期：2025-XX（请填写实际决策月份）

决策人：（填写架构组/技术负责人）

一、背景

• 订单服务长期运行在单实例/主从架构的 MySQL 上，订单量持续增长后出现明显瓶颈：大促等高峰期写入延迟上升、分库分表维护成本高、跨表查询需依赖冗余与中间件。
• 存量分库分表方案（如基于 ShardingSphere 或自研路由）导致：扩容需数据重平衡、跨分片聚合查询复杂、DDL 变更窗口长。
• 团队希望降低运维分片复杂度，并获得更好的水平扩展能力。

二、备选方案对比

| 维度 | 方案A：继续 MySQL + 加强分片 | 方案B：迁移至 TiDB | 方案C：迁移至云厂商分布式数据库（如 PolarDB-X 类产品） |

|---|---|---|---|

| 水平扩展 | 手动扩容，需数据迁移 | 存储计算分离，在线扩缩容 | 云原生扩展，绑定厂商 |

| MySQL 兼容性 | 原生 | 协议高度兼容，改动小 | 兼容性较好 |

| 分布式事务 | 跨分片依赖中间件，复杂 | 原生支持（Percolator 优化模型） | 原生支持 |

| 运维成本 | 分片规则维护、扩容窗口 | 需新增 TiDB/PD/TiKV 组件运维，或购买托管版 | 最低，但存在厂商锁定 |

| 团队熟悉度 | 高 | 中（需学习） | 中 |

三、最终决策与理由

选择方案B：迁移至 TiDB，理由：

1. 兼容性成本低：TiDB 高度兼容 MySQL 协议，订单服务以中低复杂度 SQL 为主，改造量可控。

2. 消除分片心智负担：以分布式数据库替代手工分库分表，扩容在线化、跨分片查询透明化。

3. 原生分布式事务：避免跨分片事务依赖中间件的脆弱性。

4. 生态可控：相比云厂商方案，避免深度厂商锁定；可用 TiDB Cloud 托管版进一步降低初期运维成本。

四、后续行动

• 制定灰度迁移方案：双写/影子表校验 → 数据回填一致性核对 → 按流量比例切流。
• 建立回滚预案与迁移期监控（延迟、事务冲突、热区）。
• 明确不迁移范围（如有重度依赖存储过程/触发器的模块需先评估兼容性）。

五、入库操作（你们本地执行）

```bash

git checkout -b adr-0001-tidb-migration

mkdir -p docs/adr && vim docs/adr/0001-migrate-order-service-to-tidb.md

git add . && git commit -m "docs: add ADR-0001 order service TiDB migration"

git push origin adr-0001-tidb-migration

# 然后在 GitHub 上发起 PR 合并到 main

```

> 提示：请补齐实际决策日期、决策人和当时评审记录链接，ADR 的价值在于保留“当时为什么这么选”的上下文。