[建议] 大型 UUID 索引表 (行数超过 140 万) 的运行状况分析和 ETA 超出问题

背景和运营环境

在 MySQL (Cloud SQL) 上，一个约 390GB、144M 行的生产表中，主键为 UUID（VARCHAR(36)）的情况下，我们在一次实时零停机迁移过程中遇到了两个值得注意的运营边缘情况，我们希望分享并提出改进建议：

1. 进度百分比超出和 UUID/字符串主键的预计时间计算:
   • 迁移进度持续超出 100%（达到 139%、146% 和 164.8%），在主动拷贝主键的同时，显示了 ETA: due，持续数小时。
   • 根本原因： 当迭代键不是数字（十六进制 UUID 字符串）时，EXPLAIN 中的统计估算与实际分布在词典遍历空间（0000... 到 ffff...）中存在很大差异，使操作员无法清楚地了解真正的完成时间。
2. 限流状态与推迟切换生命周期:
   • 通过 --throttle-additional-flag-file 进行长时间限流会暂停主动心跳写入和更改日志应用程序。在扩展的维护窗口中，这可能导致 MySQL 客户端连接超过 wait_timeout（28,800 秒的闲置限制）并断开连接。
   • 相比之下，使用 --postpone-cut-over-flag-file（或套接字 postpone）可以使行拷贝完成 100%，并保持连续的轻量级 binlog 流（Lag: 0.04s，主动心跳），完全防止闲置连接超时，同时安全地等待计划的切换窗口。

建议的贡献

我们希望为 gh-ost 提供以下内容：

1. 文档 PR:
   • 添加一个操作指南，明确说明在多小时的维护窗口中 --throttle-additional-flag-file（负载削减/暂停）和 --postpone-cut-over-flag-file（计划切换）之间的操作差异。
   • 文档 UUID/字母数字主键的迁移时进度指标的行为和解释。
2. 关于 ETA/指标限制的讨论:
   • 讨论检测字符串/UUID 主键的潜在启发式算法，并在 go/logic/migrator.go 中限制或权重进度估算，以避免产生 >100% / ETA: due 的混淆输出。 我们已经准备好一个本地分支，欢迎维护者提供反馈，然后再开启文档 PR！