# Amazon 数据库迁移至 TiDB 实践方案

一、概述与架构对比

1.1 迁移适用场景

以下场景推荐将 Amazon 数据库迁移至 TiDB：

• 单机容量瓶颈：MySQL 实例数据量超过 2TB，面临水平拆分压力
• 高并发写入：单实例写入 QPS 超过 5 万，需要扩展写入能力
• HTAP 需求：实时分析查询（OLAP）影响在线事务（OLTP），需要读写分离或行列混存
• 成本优化：Amazon RDS/Aurora 高规格实例成本过高，希望降低总体拥有成本（TCO）
• 数据合规：数据需要部署在特定区域或私有云环境中

1.2 架构对比

Amazon RDS / Aurora    ──→    TiDB DM / Dumpling    ──→    TiDB Cluster
(MySQL 兼容)                (迁移工具)                  (分布式 NewSQL)

二、迁移前评估与规划

2.1 兼容性检查

迁移前必须对源端数据库进行全面兼容性扫描。TiDB 虽然高度兼容 MySQL 协议，但存在部分不支持的特性：

使用 tiup 进行兼容性检查：

# 安装 tiup
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
source ~/.bash_profile

# 使用 dmctl 检查数据源兼容性
tiup dm ctl --config ./dmctl-config.toml

# 或使用 sync-diff-inspector 进行预检查
tiup install sync-diff-inspector
tiup sync-diff-inspector --config ./check-config.toml

2.2 容量规划

根据源端数据库的数据量和负载进行容量规划：

# 存储容量计算 (TiKV)
原始数据量 × 1.5（Raft 多副本系数，默认 3 副本 × 0.5）× 1.3（索引与元数据开销）
  = TiKV 所需存储总量

# 示例: 源端 500GB 数据
500GB × 1.5 × 1.3 = 975GB → 建议分配 1.2TB SSD × 3 节点

# 计算层 (TiDB Server)
# CPU: 每 1000 QPS 约需 2 Core
# 内存: 每 TiDB 实例建议 ≥ 8GB，推荐 16-32GB

# TiFlash（可选，HTAP 场景）
# 存储容量 = 原始数据量 × 1.0（列存压缩率高）

参考配置矩阵：

2.3 网络规划

网络连通性要求

• Amazon VPC 与 TiDB 目标环境之间建立 VPN / 专线连接
• 确保 DM 迁移工具所在机器可以同时访问 Amazon RDS 和 TiDB 集群
• 带宽建议 ≥ 1Gbps（数据量超过 500GB 时建议 ≥ 10Gbps）
• 防火墙放行端口：TiDB(4000), TiKV(20160), PD(2379), DM(8261/8262)

三、环境准备

3.1 TiDB 集群部署

推荐使用 TiUP 进行自动化部署。以下以 v8.1.0 为例：

# 1. 初始化集群拓扑配置
tiup cluster template --full > topology.yaml

# 2. 编辑 topology.yaml，修改关键配置
cat > topology.yaml << 'EOF'
# ---- Global Configuration ----
global:
  user: tidb
  ssh_port: 22
  deploy_dir: /data/tidb-deploy
  data_dir: /data/tidb-data
  arch: amd64

# ---- PD Servers ----
pd_servers:
  - host: 10.0.1.101
  - host: 10.0.1.102
  - host: 10.0.1.103

# ---- TiDB Servers ----
tidb_servers:
  - host: 10.0.1.201
    port: 4000
    status_port: 10080
  - host: 10.0.1.202
    port: 4000
    status_port: 10080
  - host: 10.0.1.203
    port: 4000
    status_port: 10080

# ---- TiKV Servers ----
tikv_servers:
  - host: 10.0.2.101
    port: 20160
    status_port: 20180
  - host: 10.0.2.102
    port: 20160
    status_port: 20180
  - host: 10.0.2.103
    port: 20160
    status_port: 20180

# ---- TiFlash Servers (HTAP) ----
tiflash_servers:
  - host: 10.0.3.101
  - host: 10.0.3.102

# ---- Monitoring Servers ----
monitoring_servers:
  - host: 10.0.1.200

grafana_servers:
  - host: 10.0.1.200
EOF

# 3. 执行部署（自动 SSH 到各节点）
tiup cluster deploy tidb-prod v8.1.0 topology.yaml --user tidb -i /path/to/ssh_key

# 4. 启动集群
tiup cluster start tidb-prod

# 5. 验证集群状态
tiup cluster display tidb-prod
mysql -h 10.0.1.201 -P 4000 -u root -e "SELECT * FROM information_schema.tikv_store_status;"

关键配置建议：

3.2 账号与权限配置

TiDB 端：

-- 创建迁移专用账号
CREATE USER 'dm_migration'@'%' IDENTIFIED BY 'Str0ngP@ss!2024';
GRANT ALL PRIVILEGES ON *.* TO 'dm_migration'@'%' WITH GRANT OPTION;

-- 创建业务只读验证账号
CREATE USER 'app_verify'@'%' IDENTIFIED BY 'V3rifyP@ss!';
GRANT SELECT ON `mydb`.* TO 'app_verify'@'%';

Amazon RDS 端：

-- 在 Amazon RDS 上创建迁移读取账号
CREATE USER 'dm_source'@'%' IDENTIFIED BY 'SrcP@ss!2024';
GRANT SELECT, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE,
  SHOW VIEW, SHOW DATABASES, LOCK TABLES
  ON *.* TO 'dm_source'@'%';

-- 确认 binlog 已开启
SHOW VARIABLES LIKE 'log_bin';          -- 应为 ON
SHOW VARIABLES LIKE 'binlog_format';    -- 应为 ROW
SHOW VARIABLES LIKE 'binlog_row_image'; -- 应为 FULL
SHOW VARIABLES LIKE 'gtid_mode';       -- 推荐 ON

⚠️ Amazon RDS 特别注意

• RDS 的 binlog 默认已开启，但需确认 binlog_format 为 ROW
• binlog 保留时间建议调至 ≥ 72 小时：

CALL mysql.rds_set_configuration('binlog retention hours', 72);

• 如果源端为 Aurora，需确保 binlog 从集群的 Writer 节点读取
• RDS 不允许 REPLICATION SLAVE 权限，需使用 REPLICATION CLIENT + RELOAD

四、Schema 迁移

4.1 导出源端 Schema

# 安装 Dumpling
tiup install dumpling
tiup dumpling --version

# 仅导出 Schema（不含数据）
tiup dumpling \
  -h rds-cluster.xxx.rds.amazonaws.com \
  -P 3306 \
  -u 'dm_source' \
  -p 'SrcP@ss!2024' \
  --filetype sql \
  --no-data \
  --output ./schema-export \
  --threads 8 \
  --filter 'mydb.*' \
  --consistent

# 导出结果结构:
# ./schema-export/
#   ├── mydb-schema-create.sql
#   ├── mydb.table1-schema.sql
#   ├── mydb.table2-schema.sql
#   └── metadata

4.2 Schema 兼容性修复

导出后需对 DDL 进行以下修复：

-- 1. 移除外键约束（TiDB 建议应用层维护）
ALTER TABLE orders DROP FOREIGN KEY fk_orders_customer;

-- 2. 将 AUTO_INCREMENT 替换为 AUTO_RANDOM（避免写入热点）
-- 原始 DDL:
CREATE TABLE users (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(128)
);

-- 修改后（适用于并发写入场景）:
CREATE TABLE users (
  id BIGINT AUTO_RANDOM PRIMARY KEY,
  name VARCHAR(128)
);

-- 3. 确认字符集
ALTER DATABASE mydb CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci;

-- 4. 移除 spatial index 如不使用
-- ALTER TABLE locations DROP INDEX idx_location;

-- 5. 检查并替换不支持的存储引擎
ALTER TABLE log_data ENGINE = InnoDB;  -- 确保 InnoDB

4.3 导入 Schema 到 TiDB

# 使用 TiDB Lightning 导入 Schema
tiup install tidb-lightning
tiup tidb-lightning \
  --config lightning-schema.toml

# lightning-schema.toml 关键配置:
# [lightning]
# mode = "schema"
# tidb.host = "10.0.1.201"
# tidb.port = 4000
# tidb.user = "dm_migration"
# tidb.password = "Str0ngP@ss!2024"
# mydumper.data-source-dir = "./schema-export"
# mydumper.no-schema = false
# mydumper.no-data = true

五、全量数据迁移 + 增量同步

5.1 方案选型

💡 推荐方案 A：使用 TiDB DM 进行在线迁移

DM（Data Migration）是 TiDB 官方数据迁移工具，支持将 MySQL/MariaDB 数据全量+增量实时同步到 TiDB，是最推荐的迁移方案。

5.2 DM 部署与配置

# 1. 部署 DM 集群（2 个 worker + 1 个 master）
tiup dm template --full > dm-topology.yaml

# 2. 编辑 dm-topology.yaml
# dm_master_servers:
#   - host: 10.0.4.101
#     port: 8261
# dm_worker_servers:
#   - host: 10.0.4.201
#     port: 8262
#   - host: 10.0.4.202
#     port: 8262

# 3. 部署并启动
tiup dm deploy dm-prod v8.1.0 dm-topology.yaml --user tidb -i /path/to/ssh_key
tiup dm start dm-prod

# 4. 验证 DM 集群状态
tiup dm list dm-prod

5.3 配置迁移任务

# ====================
# Amazon RDS → TiDB 迁移任务配置
# ====================
---
name: aws-to-tidb-migration
task-mode: all              # all = 全量 + 增量
shard-mode: pessimistic     # 悲观模式（推荐）

# ---- 源端 (Amazon RDS) ----
target-database:
  host: 10.0.1.201
  port: 4000
  user: "dm_migration"
  password: "Str0ngP@ss!2024"

mysql-instances:
  - source-id: "aws-rds-source"
    route-rules: ["mydb-route-rule"]
    server-id: 1000001                  # 唯一 server-id
    source-config:
      connection-config:
        host: rds-cluster.xxx.rds.amazonaws.com
        port: 3306
        user: "dm_source"
        password: "SrcP@ss!2024"
        security:
          ssl-ca: "/path/to/rds-ca.pem"     # Amazon RDS SSL 证书
          ssl-cert: "/path/to/rds-client-cert.pem"
          ssl-key: "/path/to/rds-client-key.pem"
      checker:
        check-enable: true
        check-thread: 4
        backoff-max: 60s

    # ---- 过滤规则 ----
    filters:
      - "filter-out-system"

filter-rules:
  - filter-out-system
    schema-pattern: "mysql|information_schema|performance_schema|sys|_tidb_*"
    action: Ignore

# ---- 表路由 ----
routes:
  - mydb-route-rule
    schema-pattern: "mydb"
    target-schema: "mydb"
    table-pattern: "*"
    target-table: "*"

# ---- 表结构迁移规则 ----
block-allow-list:
  list-name: "mydb-allow"
  do-dbs: ["mydb"]

# ---- 导出/加载/同步配置 ----
    mydumpers:
      thread: 8                      # 全量导出并发线程
      chunk-size: 64                  # 每批数据行数（MB）
      extra-args: "--rows 1000000"    # Dumpling 参数

    loaders:
      pool-size: 16                   # 全量导入并发
      dir: "./dumped_data"

    syncers:
      worker-count: 16                # 增量同步并发
      batch: 1000                     # 批量大小
      safe-mode: false                # 生产环境关闭 safe-mode

# ---- 出错处理 ----
on-duplication-error-replace: false  # 遇到重复数据报错而非替换
error-count-limit: 100              # 错误累计上限

5.4 启动迁移任务

# 1. 预检查迁移任务
tiup dm ctl --config ./dmctl-config.toml check-task ./task-config.yaml

# 2. 启动迁移任务
tiup dm ctl --config ./dmctl-config.toml start-task ./task-config.yaml

# 3. 监控迁移进度
tiup dm ctl --config ./dmctl-config.toml query-status aws-to-tidb-migration

# 4. 查看全量迁移进度
tiup dm ctl --config ./dmctl-config.toml show-ddl-locks

# 输出示例：
# {
#   "result": true,
#   "msg": "check pass!!",
#   "sources": [{
#     "source": "aws-rds-source",
#     "worker": "dm-worker-1",
#     "stage": "Running",           ← 当前阶段
#     "unit": "Sync",              ← 全量/增量阶段
#     "progress": "82.35%",
#     "total": 1258643200,
#     "finished": 1036800000
#   }]
# }

5.5 增量同步阶段管理

# 查看增量同步延迟
tiup dm ctl --config ./dmctl-config.toml \
  query-status aws-to-tidb-migration | grep "Syncer"

# 暂停迁移任务（维护窗口）
tiup dm ctl --config ./dmctl-config.toml pause-task aws-to-tidb-migration

# 恢复迁移任务
tiup dm ctl --config ./dmctl-config.toml resume-task aws-to-tidb-migration

# 停止迁移任务
tiup dm ctl --config ./dmctl-config.toml stop-task aws-to-tidb-migration

# 处理冲突（如主键重复）
tiup dm ctl --config ./dmctl-config.toml \
  handle-error "aws-to-tidb-migration" skip "aws-rds-source:mysqld-bin.000123:45678"

🚨 迁移注意事项

• 全量迁移期间不要执行 DDL 操作，避免 binlog 顺序错乱
• 监控源端 RDS 的负载，避免全量导出拖垮在线业务
• 增量同步阶段需密切关注延迟，确保控制在 5 秒以内
• 如果全量数据超过 500GB，建议在业务低峰期启动全量迁移

六、数据校验

数据迁移完成后，必须进行严格的数据一致性校验。TiDB 官方提供 sync-diff-inspector 工具：

# diff-config.toml

# ---- 源端 (Amazon RDS) ----
[data-sources]
[data-sources.mysql]
  host = "rds-cluster.xxx.rds.amazonaws.com"
  port = 3306
  user = "dm_source"
  password = "SrcP@ss!2024"

# ---- 目标端 (TiDB) ----
[data-sources.tidb]
  host = "10.0.1.201"
  port = 4000
  user = "dm_migration"
  password = "Str0ngP@ss!2024"

# ---- 校验任务配置 ----
[task]
  output-dir = "./diff-output"
  source-instances = ["mysql"]
  target-instance = "tidb"
  target-check-tables = ["mydb.*"]

  # 分片校验配置（大表拆分校验）
  [[table-config.source-tables]]
    schema = "mydb"
    table  = "orders"
    split-column = "id"
    split-range = [0, 5000000, 10000000, 15000000]

  # 校验选项
  [task.check-options]
    check-insert = true        # 校验多余行
    check-update = true        # 校验不一致值
    check-delete = true        # 校验缺失行
    chunk-size = 10000         # 每批校验行数
    sample-percent = 100      # 抽样百分比（100=全量校验）
    thread = 8                 # 校验并发线程

# 执行数据校验
tiup sync-diff-inspector diff-config.toml

# 输出示例（成功）：
# [2024-01-15 10:30:00] Check passed!
# A total of 50 tables have been checked and all data is consistent.

# 输出示例（不一致）：
# [2024-01-15 10:30:00] Check failed!
# mysqldiff.table_diff report saved to: ./diff-output/summary.txt

# 查看差异报告
cat ./diff-output/summary.txt

业务层校验：

-- 1. 表行数校验
SELECT
  TABLE_NAME,
  TABLE_ROWS,
  ROUND(DATA_LENGTH / 1024 / 1024, 2) AS data_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'mydb'
ORDER BY TABLE_ROWS DESC;

-- 2. 聚合值校验
SELECT COUNT(*) AS total_rows,
       SUM(amount) AS total_amount,
       MAX(created_at) AS latest_record
FROM orders;

-- 3. 采样比对（在源端和目标端分别执行）
SELECT id, amount, status, created_at
FROM orders
WHERE id % 1000 = 0
ORDER BY id
LIMIT 1000;

七、性能调优

7.1 TiDB 核心参数调优

7.2 索引优化

-- 1. 查看热点表和热点索引
SELECT * FROM information_schema.tikv_region_status
WHERE written_keys > 100000 ORDER BY written_keys DESC;

-- 2. 统计信息手动收集（迁移后必须）
ANALYZE TABLE mydb.orders;
ANALYZE TABLE mydb.users;
ANALYZE TABLE mydb.order_items;

-- 3. 全库统计信息收集
SET GLOBAL tidb_auto_analyze_ratio = 0.5;
SET GLOBAL tidb_auto_analyze_start_time = '03:00 +0800';
SET GLOBAL tidb_auto_analyze_end_time = '05:00 +0800';

-- 4. 查看慢查询
SELECT query_time, total_keys, sql_text
FROM information_schema.slow_query
ORDER BY query_time DESC
LIMIT 20;

7.3 高可用配置

# 确认副本分布在不同可用区（AZ）
# SQL:
SELECT
  store_id, address, state_name,
  ROUND(capacity / 1024 / 1024 / 1024, 2) AS capacity_gb,
  available
FROM information_schema.tikv_store_status;

# 配置标签实现 AZ 感知调度
tiup ctl vd --host 10.0.1.101:2379 \
  store label 1 zone az1

tiup ctl vd --host 10.0.1.101:2379 \
  config set replication.location-labels "zone"

八、业务验证与压测

验证流程：

1. 功能验证：在 TiDB 环境运行完整的业务功能测试用例，覆盖所有 CRUD 操作、事务、存储过程等关键业务逻辑
2. 性能基准测试：使用 sysbench / mysqlslap / 自定义压测工具，对比源端和目标端的 QPS、响应延迟、吞吐量
3. 故障注入测试：模拟节点宕机、网络分区等故障场景，验证 TiDB 的自动恢复和业务影响
4. 灰度验证：将部分非核心业务流量路由到 TiDB，观察 1-2 周，确认稳定后再全量切换

8.1 Sysbench 压测

# 安装 sysbench
apt-get install sysbench

# OLTP 读写混合测试
sysbench oltp_read_write \
  --threads=64 \
  --time=600 \
  --report-interval=10 \
  --tables=64 \
  --table-size=1000000 \
  --db-driver=mysql \
  --mysql-host=10.0.1.201 \
  --mysql-port=4000 \
  --mysql-user=dm_migration \
  --mysql-password='Str0ngP@ss!2024' \
  --mysql-db=mydb \
  run

# OLTP 只写测试
sysbench oltp_write_only \
  --threads=32 --time=300 \
  --mysql-host=10.0.1.201 --mysql-port=4000 \
  --mysql-user=dm_migration --mysql-password='Str0ngP@ss!2024' \
  --mysql-db=mydb \
  run

8.2 性能指标参考

九、切换上线

9.1 切换流程

Step 1 → 确认增量同步追平（DM 延迟 < 1 秒）
    ↓
Step 2 → 设置 RDS 只读模式
    ↓
Step 3 → 等待 DM 追完剩余数据
    ↓
Step 4 → 最终数据一致性校验
    ↓
Step 5 → 修改应用连接串指向 TiDB
    ↓
Step 6 → 验证业务正常运行
    ↓
Step 7 → 停止 DM 任务

# Step 1: 检查 DM 增量延迟
tiup dm ctl --config ./dmctl-config.toml query-status aws-to-tidb-migration

# Step 2: RDS 设为只读（AWS CLI）
aws rds modify-db-instance \
  --db-instance-identifier my-rds-instance \
  --enable-read-replica \
  --apply-immediately

# Step 3: 等待并确认（间隔 30 秒检查 DM 状态）
watch -n 30 "tiup dm ctl --config ./dmctl-config.toml query-status aws-to-tidb-migration"

# Step 4: 最终校验
tiup sync-diff-inspector diff-config.toml

# Step 5: 切换应用连接（以 Spring Boot 为例）
# application.yml:
# spring:
#   datasource:
#     url: jdbc:mysql://10.0.1.201:4000/mydb?useSSL=false&serverTimezone=Asia/Shanghai

# Step 7: 停止 DM 任务
tiup dm ctl --config ./dmctl-config.toml stop-task aws-to-tidb-migration

⚠️ 切换窗口建议

• 选择业务低峰期（如凌晨 2:00 - 5:00）
• 准备回滚方案（保留 RDS 实例至少 7 天）
• 通知相关团队（DBA、开发、运维、业务方）
• 提前准备应急联系渠道

9.2 回滚方案

🚨 回滚条件 — 出现以下任一情况，应立即启动回滚：

• TiDB 集群不可用或连续错误超过 5 分钟
• 关键业务流程出现严重错误（如订单丢失、金额计算错误）
• P99 延迟超过业务可接受阈值的 3 倍

# 1. 将应用连接切回 Amazon RDS

# 2. 将 RDS 恢复为可读写
aws rds modify-db-instance \
  --db-instance-identifier my-rds-instance \
  --no-enable-read-replica \
  --apply-immediately

# 3. 使用 DM 反向同步切换期间 TiDB 端产生的数据
# 需要重新配置 DM 任务，将 TiDB 作为源端，RDS 作为目标端
# 注意：反向同步需要开启 TiDB 的 binlog（TiDB v7.x+ 支持）

-- TiDB 开启 binlog（用于反向同步）
SET GLOBAL tidb_enable_binlog = 1;

-- 4. 验证 RDS 端数据完整性
SELECT COUNT(*) FROM orders WHERE updated_at > '2024-01-15 02:00:00';

十、迁移后优化

10.1 统计信息与执行计划

-- 1. 全库收集统计信息
SET GLOBAL tidb_auto_analyze_ratio = 0.3;
ANALYZE TABLE mydb.orders HISTOGRAM ON id, user_id, status, created_at;

-- 2. 检查执行计划绑定（确保关键查询走正确索引）
CREATE BINDING FOR
  SELECT * FROM orders WHERE user_id = ? AND status = ?
  USING SELECT /*+ USE_INDEX(orders idx_user_status) */ * FROM orders WHERE user_id = ? AND status = ?;

-- 3. 查看绑定状态
SHOW GLOBAL BINDINGS;

10.2 监控告警配置

10.3 备份策略

# 全量备份到 S3 / 本地存储
tiup br backup full \
  --pd "10.0.1.101:2379" \
  --storage "s3://my-backup-bucket/tidb-backup?access-key=XXX&secret-access-key=YYY&endpoint=s3.amazonaws.com" \
  --send-credentials-to-tikv=true \
  --compression lz4

# 增量备份（基于日志）
tiup br backup point \
  --pd "10.0.1.101:2379" \
  --storage "s3://my-backup-bucket/tidb-incremental" \
  --start-ts 433883834356060161 \
  --end-ts 433883834356060162

# 定时备份 (crontab 示例: 每天凌晨 3 点全量备份)
# 0 3 * * * tiup br backup full --pd "10.0.1.101:2379" --storage "s3://..." --compression lz4

十一、常见问题 FAQ

Q1: 迁移过程中 DM 报 "driver: bad connection" 怎么办？

通常是因为 Amazon RDS 连接超时或 SSL 配置问题。检查以下几点：

• 确认 DM Worker 所在机器到 RDS 的网络连通性
• 检查 SSL 证书路径是否正确
• 在 DM source-config 中增加 connection-config 参数：max-idle-connections、max-open-connections
• RDS 安全组是否放行了 DM Worker 的 IP

Q2: 全量迁移速度很慢怎么办？

优化建议：

• 增大 mydumpers.thread 参数（建议 8-16）
• 增大 loaders.pool-size 参数（建议 16-32）
• 检查 TiKV 磁盘 IOPS 是否达到瓶颈
• 临时关闭 TiDB 的限流参数
• 增加 DM Worker 节点数

Q3: 迁移后某些查询变慢了？

迁移后必须收集统计信息，否则优化器可能选择错误的执行计划：

-- 强制收集全库统计信息
SET GLOBAL tidb_auto_analyze_ratio = 0.01;
ANALYZE DATABASE mydb;

-- 对关键表收集 Histogram
ANALYZE TABLE orders HISTOGRAM ON user_id, status;

-- 使用 EXPLAIN ANALYZE 查看实际执行计划
EXPLAIN ANALYZE
SELECT * FROM orders WHERE user_id = 1000 AND status = 1;

Q4: AUTO_ID 热点问题如何处理？

TiDB 默认的 AUTO_INCREMENT 使用单一自增序列，会导致写入集中在单个 Region。解决方案：

• 新表使用 AUTO_RANDOM 代替 AUTO_INCREMENT
• 已有表通过 ALTER TABLE ... AUTO_RANDOM 修改
• 业务层使用分布式 ID 生成器（如 Snowflake）

Q5: 大事务导致 OOM 怎么办？

TiDB 分布式事务对大事务敏感。建议：

• 设置事务大小限制：SET GLOBAL txn-entry-size-limit = 62914560;（60MB）
• 拆分大批量操作（如 DELETE 分小批量执行）
• Batch Insert 每批不超过 5000 行
• 使用 SET GLOBAL txn-local-lifecycle-limit = 1000000; 限制事务操作数

Q6: 从 Aurora Serverless 迁移有什么特殊注意？

Aurora Serverless v2 支持 binlog，但需要注意：

• 必须将集群容量暂时提升以确保 binlog 写入性能
• Serverless 的连接数限制可能导致 Dumpling 导出超时
• 建议在迁移期间将 Aurora 切换为 Provisioned 模式

适用版本：TiDB v7.x / v8.x 源端：Amazon RDS MySQL / Aurora MySQL 参考资料

• TiDB 官方迁移文档
• TiDB MySQL 兼容性说明
• TiDB DM 官方文档
• sync-diff-inspector 使用文档