>迁移跑完，进度条停在 95% 不动，你以为卡死了——其实数据早就同步完了。另一个更隐蔽：几百万行的大表迁完，行数跟源库对不上，查半天查不出原因。这两件事都真实发生在 MySQL2PG 上，这次一刀全切了。

先给新朋友一句话介绍：**MySQL2PG** 是一款 Go 编写的数据库迁移工具，把 MySQL 完整搬迁到 PostgreSQL——表结构、数据、索引、视图、函数、用户权限，全都能转。
## 01 MySQL2PG 能干什么


| | |
|:-:|:-:|
|能力|说明|
|表结构转换|解析 `SHOW CREATE TABLE`，40+ 类型映射，覆盖 UNSIGNED / BIT / ZEROFILL 边界|
|高性能数据同步|批量读取 + `pgx.CopyFrom` 批量写入，并发调度，吞吐量提升 5~8 倍|
|索引重建|主键、唯一、普通、全文索引|
|视图 / 函数转换|42 个视图、113 个函数 100% 可转换|
|用户与权限|MySQL 用户 → PostgreSQL 角色，GRANT 语句自动转换|
|数据校验|同步后逐表比对行数，不一致直接列清单|
|HTML 迁移报告|一条命令生成单文件可视化报告|
版本兼容：MySQL 5.7+ / 8.0+ → PostgreSQL 12 ~ 18，Go 1.24+ 构建。
三条命令上手：
```
git clone https://github.com/xfg0218/MySQL2PG.git && cd MySQL2PG make build &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# 构建 cp config.example.yml config.yml &nbsp; # 复制配置，填入源库/目标库连接信息
```迁移前先确认连接没问题：
```
# test_only 模式：只测连接、打印版本，不做任何转换，1 秒内结束 ./mysql2pg config.yml
```官网 **mysql2pg.com** 有工具介绍和获取入口。
## 02 数据同步链路是怎么跑的

动刀之前先看链路。数据同步调用链：
```
SyncTableData() &nbsp; → 启动专用进度消费者 goroutine &nbsp; → 按表并发派发（信号量控制并发数，默认 10） &nbsp; &nbsp; → syncSingleTable() &nbsp; &nbsp; &nbsp; → truncateTable() &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # 可选：同步前清空目标表 &nbsp; &nbsp; &nbsp; → paginateAndInsert() &nbsp; &nbsp; &nbsp; &nbsp; → mysqlConn.GetTableData() &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# 分页读 MySQL &nbsp; &nbsp; &nbsp; &nbsp; → postgresConn.BatchInsertDataWithCompositeKeys() &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # pgx.CopyFrom 批量写 PostgreSQL &nbsp; &nbsp; &nbsp; → validateData() &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# 行数一致性校验
```分页策略按源表条件四选一：

| | | |
|:-:|:-:|:-:|
|源表条件|读取策略|复杂度|
|单列主键|键集分页 `WHERE pk > last_pk`|O(n)|
|复合主键|行构造器 `(pk1, pk2) > (?, ?)`|O(n)|
|无主键，≤200 万行|流式读取（单次查询 + 迭代分批插入）|O(n)|
|无主键，>200 万行|OFFSET 分页 + 全列排序|O(n²)|
有主键的表永远不会走 OFFSET——键集分页走索引定位，不用逐行扫过丢弃。问题就出在最后一档：无主键大表的兜底路径。
一个顺手的细节：Ctrl+C 取消时只停止派发新表，进行中的批次用 `context.WithoutCancel` 派生批次上下文，完整提交后才退出。中途打断不会留半批脏数据。
## 03 第一台手术：进度条的三宗罪

### 现象

进度条冲到 95%，然后就没有然后了。等半天，完成信息迟迟不出现。
### 诊断过程

#### Step 1: 同步真的卡住了吗

```
# 检查日志里各表是否已完成 grep "同步完成" conversion.log | wc -l # 每张表都有完成记录 → 数据干完了，卡的只是显示层
```→ 结论：**排除**同步挂起。
#### Step 2: 进度更新去哪了

旧消费者逻辑带 500ms 节流，窗口内到达的更新被**直接丢弃**：
```
// 旧逻辑（已修复）：select-default 丢弃模式 select { case progressChan <- update: default: &nbsp; &nbsp; // 直接丢弃——最后一批的更新几乎总是死在这里 }
```小表几百毫秒跑完，所有更新都落在节流窗口内；大表最后一批距离上次渲染通常不足 500ms——100% 那次更新必被吞。原来如此：**不是没到 100%，是 100% 的更新被丢了**。
→ 结论：锁定根因①——节流用丢弃而非合并，最终状态必丢。
#### Step 3: 完成消息为什么被抹掉

进度行靠 `\033[2K\r`（清行 + 回车）原地刷新，行尾不带换行。其他日志直接打印、不先给进度行收尾，下一次进度刷新直接把它抹掉。
→ 结论：锁定根因②——多路输出抢同一行，没人协调。
#### Step 4: CI 日志里的乱码是什么

```
[2K\r 62.5% | orders | ████...
```ANSI 转义码只有终端认识，重定向到文件就是垃圾字符。旧逻辑无条件输出。
→ 结论：锁定根因③——不检测输出端。
### 修复：专用消费者 + 输出协调器

```
// 文件路径：internal/converter/postgres/sync_data.go &nbsp;MySQL2PG@422c4e9 // 核心：高频更新只保留最新值（合并渲染），通道关闭后补渲染最终状态 func consumeProgressUpdates(ch <-chan progressUpdate, p *progressPrinter) { &nbsp; &nbsp; var latest *progressUpdate &nbsp; &nbsp; var lastRender time.Time &nbsp; &nbsp; for update := range ch { &nbsp; &nbsp; &nbsp; &nbsp; latest = &update // ← 关键：始终保留最新值，不再丢弃 &nbsp; &nbsp; &nbsp; &nbsp; if time.Since(lastRender) >= progressUpdateInterval { &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; p.render(*latest) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; latest = nil &nbsp; &nbsp; &nbsp; &nbsp; } &nbsp; &nbsp; } &nbsp; &nbsp; if latest != nil { &nbsp; &nbsp; &nbsp; &nbsp; p.render(*latest) // ← 通道关闭后补渲染最终状态，100% 必达 &nbsp; &nbsp; } &nbsp; &nbsp; p.endLine() }
```这个结构体就是输出协调器，两条规矩：  
进度行只由专用消费者 goroutine 写，别人不许碰
任何普通行打印前先 `endLine()`，结束未收尾的进度行


终端检测只用标准库，不引依赖：
```
func isTerminalOutput(f *os.File) bool { &nbsp; &nbsp; fi, err := f.Stat() &nbsp; &nbsp; if err != nil { &nbsp; &nbsp; &nbsp; &nbsp; return false &nbsp; &nbsp; } &nbsp; &nbsp; return fi.Mode()&os.ModeCharDevice != 0 }
```修完后终端里长这样（示意）：
```
62.5% | orders | █████████████████████████░░░░░░░░░░░░░░░ | 3,125,000/5,000,000 rows | 125.0K rows/s | ETA: 15s
```### 设计权衡


| | | |
|:-:|:-:|:-:|
|方案|优点|问题|
|worker 直接 Printf|最简单|多 worker 交错，清行码互相抹|
|全局 mutex + 同步渲染|实现容易|I/O 阻塞 worker，高频更新锁竞争|
|专用消费者 + 合并渲染|worker 只做无阻塞发送|多一个 goroutine（选用）|
worker 侧只干一件事：往带缓冲通道塞更新。塞不进去也不影响数据同步——进度是锦上添花，不是关键路径。
### 附赠修复：一个换行符的连锁反应

完成日志原本带个前导 `\n`，想让它在终端里跟进度条隔开。但 HTML 报告的日志解析器按行正则匹配——这个换行把时间戳和内容拆成两行，非空表的同步状态从此在报告里消失。一并移除。
一个换行符，上游是终端显示，下游是报告链路。改的时候只盯一处，就是埋雷。
### 边界探测


| | | | |
|:-:|:-:|:-:|:-:|
|场景|预期|实际|洞察|
|输出重定向到文件|无 ANSI 乱码|render 直接跳过|字符设备检测生效|
|空通道直接关闭|无输出|无输出|无更新不渲染|
|连续 3 次快发后关闭|必显 100%|渲染最终状态 + 收尾换行|合并不丢弃生效|
|processed > total|不显示 103%|封顶 100.0%|边界保护|
## 04 第二台手术：无主键 + OFFSET = 丢行陷阱

这是三个里最危险的一个。
### 机制

对**没有主键、行数超过 200 万**的表，工具只能退回 OFFSET 分页：
```
-- 第 1 页 SELECT * FROM big_table LIMIT 50000 OFFSET 0; -- 第 2 页 SELECT * FROM big_table LIMIT 50000 OFFSET 50000;
```问题在于：MySQL 对**不带 ORDER BY** 的查询不保证行序。优化器根据统计信息、缓冲状态选择访问路径，两次分页查询的扫描顺序可能对不上——某一行在两页都出现（重复），或者两页都没出现（丢失）。
概率不高，所以一直没被发现。但数据一致性这种事，概率再低也是 0 和 1 的区别。
### 量化推演：OFFSET 有多贵

OFFSET 分页不光是正确性问题，性能还是 O(n²)：
```
表行数 n = 5,000,000，每批 B = 50,000 分页数 = n / B = 100 页 &nbsp;MySQL 读第 i 页，要先扫描并丢弃 OFFSET 行： &nbsp; 累计丢弃行数 = B × (0 + 1 + 2 + ... + 99) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 50,000 × 4,950 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 247,500,000 行 &nbsp; 累计扫描 ≈ 247.5M + 5M ≈ 2.5 亿行 &nbsp; &nbsp;≈ 表行数的 50 倍
```500 万行的表，MySQL 实际扫了 2.5 亿行。这就是 OFFSET 的代价——也是为什么有主键一定要用键集分页。
### 修复：全列排序保确定性

```
// 文件路径：internal/converter/postgres/sync_data.go &nbsp;MySQL2PG@4d3f57f // buildOffsetOrderBy 为无主键表的 OFFSET 分页生成确定性排序子句（全列排序） func buildOffsetOrderBy(columns []string, columnTypes map[string]string) string { &nbsp; &nbsp; quoted := make([]string, 0, len(columns)) &nbsp; &nbsp; for _, col := range columns { &nbsp; &nbsp; &nbsp; &nbsp; if !isSortableColumnType(columnTypes[col]) { // JSON/空间类型不可排序，排除 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; continue &nbsp; &nbsp; &nbsp; &nbsp; } &nbsp; &nbsp; &nbsp; &nbsp; quoted = append(quoted, "`"+strings.ReplaceAll(col, "`", "``")+"`") &nbsp; &nbsp; } &nbsp; &nbsp; return strings.Join(quoted, ", ") }
```三个细节：
**JSON、空间类型（GEOMETRY / POINT 等）不能直接参与 ORDER BY**，不排除会直接报 SQL 错误  
列名反引号包裹，内嵌反引号双写转义
全表找不到一个可排序列时，不静默跑——输出明确警告

```
警告: 表 xxx 无主键且行数较大，采用 OFFSET 分页（复杂度 O(n²)）， 且无可排序列，无法保证分页确定性，跨页可能重复或漏行，建议源表添加主键
```顺带说明：TEXT / BLOB 列排序受 MySQL `max_sort_length` 前缀限制，前缀完全相同的超长文本之间理论上仍可能乱序——概率极低，但边界要讲清楚。
>**建议**：源表无主键且行数超过 200 万的，迁移前先加主键。工具侧兜底只能保正确，救不了 O(n²)。

## 05 第三台手术：TRUNCATE 里的一个双引号

`truncate_before_sync=true` 时，同步前清空目标表。原来的 SQL 拼接：
```
// 修复前 truncateQuery := fmt.Sprintf("TRUNCATE TABLE %s", tableName)
```表名带双引号或 PostgreSQL 保留字，轻则语法错误，重则语句被截断。PostgreSQL 的标识符规矩：双引号包裹，内部双引号双写转义。
```
// 文件路径：internal/converter/postgres/sync_data.go &nbsp;MySQL2PG@4d3f57f truncateQuery := fmt.Sprintf("TRUNCATE TABLE %s", quotePGIdentifier(tableName)) &nbsp;// 文件路径：internal/converter/postgres/sync_user_privilege.go func quotePGIdentifier(name string) string { &nbsp; &nbsp; return `"` + strings.ReplaceAll(name, `"`, `""`) + `"` }
```复用用户权限模块里已有的转义函数，全项目行为一致。一行改动，但这种细节决定工具在关键时刻靠不靠得住。
## 06 顺手聊聊：为什么敢一批 5 万行

朴素实现用 `*interface{}` 接收 Scan，每行再 `make([]interface{})`。算笔账：
```
每批 50,000 行，20 列宽表： &nbsp; Scan 装箱 &nbsp; &nbsp;= 50,000 × 20 = 1,000,000 次 interface{} 分配 &nbsp; 行切片分配 &nbsp; = 50,000 次 make([]interface{}, 20) &nbsp; 文本列转换 &nbsp; = 每行每列一次 []byte → string 复制 &nbsp; → 单批堆分配 ≈ 60MB，GC 压力爆炸，越跑越慢
```MySQL2PG 的三个优化：

| | | |
|:-:|:-:|:-:|
|优化点|做法|效果|
|Scan 目标|按列类型预分配 `*int64` / `*string` / `*[]byte`|每行 0 次堆分配|
|行切片|`sync.Pool` 复用 `[]interface{}` 底层数组|切片分配 -99.9%|
|文本直通|`[]byte` 直传 CopyFrom，不做 string 转换|字符串分配 -99.6%|
```
优化效果（50,000 行/批）： &nbsp; 单批堆分配：60MB → 0.4MB（-99.2%） &nbsp; 吞吐量：提升 5~8 倍
```再叠一层自适应批大小：按列类型估算行宽（varchar 按声明长度、大对象统一按 1KB），单批内存封顶 64MB。超宽表（1MB/行）自动降到 64 行/批，保底 1 行。宽表不 OOM，窄表不降速。
## 07 怎么验证

全部改动在 `-race` 并发检测下过完整测试：
```
go build ./... && go vet ./... &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# 构建 + 静态检查 go test -race -count=1 ./... &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# 带并发检测的完整测试 # ok &nbsp;internal/converter/postgres # ok &nbsp;internal/report
```本次新增 9 个单元测试：输出协调、合并渲染、最终状态、排序子句生成、标识符转义。项目整体还有 84 个集成测试用例、193 张测试表，覆盖全部类型边界。
两个修复已推送 GitHub：
```
git log --oneline -2 # 4d3f57f fix: no-PK OFFSET pagination determinism + TRUNCATE identifier escaping # 422c4e9 fix: data-sync progress display — line tearing, missing final render, ANSI in non-tty
```## 08 使用建议

**先做迁移评估**：`test_only: true`，1 秒验证连接和版本，不碰任何数据  
**给源表加主键**：无主键大表的根治方案，O(n²) 谁都救不了
**大表分批迁**：`use_table_list: true` 配表白名单，核心表先跑
**幂等重跑**：`truncate_before_sync: true` 配合 `skip_existing_tables`，随时可重来
**迁完生成报告**：

```
./mysql2pg report -l conversion.log # → 生成 report-YYYY-MM-DD_HHmmss.html，浏览器直接打开
```进度、耗时、异常清单，一屏看全。
## 局限与不适用场景

- **进度条修复只动显示层**：它解决的是"卡在 95%"的假象，不解决同步本身慢的问题——大表慢是源库读取 + 目标写入的物理瓶颈，得靠分页策略和批大小
- **OFFSET 兜底有三个边界**：TEXT/BLOB 前缀排序理论上仍可能乱序、全表无排序列时只警告不保确定性、200 万行阈值是经验值而非精确分界
- **工具不修源库数据**：脏数据、重复行会原样搬过去；无主键表的重复/丢失风险，根治方案永远是在源库先加主键
- **先演练再上生产**：建议在测试库跑完整流程、核对报告里每张表的行数与状态，再切生产

## 总结
**进度条重构**：专用消费者 + 合并渲染，100% 状态必达，CI 日志无乱码
**分页确定性**：无主键大表 OFFSET 兜底加全列排序，不再静默重复丢行
**标识符转义**：TRUNCATE 统一走标准转义，特殊表名不翻车
**性能底座**：单批堆分配 0.4MB、自适应批大小、吞吐量 5~8 倍
**诚实边界**：OFFSET 兜底保正确救不了 O(n²)，无主键大表先加主键是根治
**验证闭环**：`-race` 全量测试 + 9 个新单测 + 84 个集成用例兜底

迁移工具没有魔法，可靠性是一行行细节堆出来的。如果你正在规划 MySQL 到 PostgreSQL 的迁移，不妨试试。
**互动提问**：你在迁库时踩过进度条假死、行数对不上的坑吗？最后是怎么定位的？评论区聊聊。
**转发理由**：转发给正在规划 MySQL→PG 迁移、或者被无主键大表折磨过的 DBA 同事——这三台手术可能帮他省下好几个通宵。
### 引用链接

- **MySQL2PG 官网**：mysql2pg.com 
- **GitHub 仓库**：https://github.com/xfg0218/MySQL2PG
- **MySQL SELECT 文档（无 ORDER BY 不保证行序）**：https://dev.mysql.com/doc/refman/8.0/en/select.html
- **pgx CopyFrom**：https://pkg.go.dev/github.com/jackc/pgx/v5

迁移跑完，进度条停在 95% 不动，你以为卡死了——其实数据早就同步完了。另一个更隐蔽：几百万行的大表迁完，行数跟源库对不上，查半天查不出原因。这两件事都真实发生在 MySQL2PG 上，这次一刀全切了。

进度条卡在 95%、无主键大表悄悄丢行：MySQL2PG 数据同步的三台手术

高级数据库开发工程师

数据库

开发工具

后端

MySQL2PG迁移工具修复三大隐患：进度条假死、无主键大表丢行、TRUNCATE转义错误。重构进度显示机制，采用全列排序保证OFFSET分页确定性，优化批量写入性能提升5-8倍。兼容MySQL5.7+/8.0+至PostgreSQL12-18，支持表结构、数据、视图、函数及权限全量迁移。

数据一致性

数据同步

代码解释

PostgreSQL

GitHub

MySQL

JSON

腾讯云数据库特惠，新用户首单0.5折起


2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

进度条卡在 95%、无主键大表悄悄丢行：MySQL2PG 数据同步的三台手术-腾讯云开发者社区-腾讯云

进度条卡在 95%、无主键大表悄悄丢行：MySQL2PG 数据同步的三台手术

进度条卡在 95%、无主键大表悄悄丢行：MySQL2PG 数据同步的三台手术

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐