4. 超时原因分析：网络延迟、锁等待、大事务、资源争用、慢查询导致的超时
数据库迁移任务超时是异步系统中最为棘手的故障模式之一。超时并非单一原因所致，而是多种底层因素叠加的结果。本章从系统架构与数据库内核两个维度，逐一拆解导致超时的五大根因：网络延迟、锁等待、大事务、资源争用与慢查询。理解这些原因，是设计有效重试与恢复策略的前提。
4.1 超时根因全景图
下图展示了五种超时原因在数据库迁移链路中的分布位置与相互影响关系。每个节点代表一个独立的故障域，箭头表示因果传导路径。
4.2 网络延迟
网络延迟是分布式数据库迁移中最常见、也最容易被忽视的超时原因。它并非数据库本身的问题，而是通信链路上的瓶颈。
| 延迟类型 | 典型场景 | 影响范围 | 检测手段 |
|---|---|---|---|
| 物理距离延迟 | 跨地域数据中心迁移 | 每次往返增加 10-100ms | ping / traceroute |
| 网络拥塞延迟 | 带宽不足、突发流量 | 丢包率上升，重传加剧 | iftop / nload |
| TCP 握手延迟 | 频繁建立短连接 | 每次握手增加 1-3 RTT | 连接池监控 |
| DNS 解析延迟 | 域名解析超时或失败 | 首次连接增加 1-5s | dig +trace |
实践建议：在迁移脚本中预先执行
SELECT 1 心跳检测，并设置独立的网络超时阈值（通常为 5s），与业务查询超时（通常为 30s）分开配置。
4.3 锁等待
锁等待是数据库内部最常见的超时诱因。当迁移任务尝试获取行锁、表锁或元数据锁时，若被其他事务持有，则进入等待状态。等待时间超过 innodb_lock_wait_timeout（默认 50s）即触发超时。
关键参数：MySQL 中
innodb_lock_wait_timeout 默认 50 秒，lock_wait_timeout 默认 31536000 秒（1年）。迁移任务应显式设置 innodb_lock_wait_timeout = 10，避免长时间阻塞。
4.4 大事务
大事务是数据库迁移的“隐形杀手”。单条 DDL 或大批量 DML 语句产生的事务，可能持续数分钟甚至数小时。大事务不仅自身容易超时，还会引发连锁反应：
- undo 膨胀：大事务需要保留大量 undo 日志，导致磁盘 I/O 飙升。
- binlog 堆积：主从复制延迟加剧，从库可能因 relay log 满而中断。
- 锁范围扩大：InnoDB 行锁可能升级为间隙锁或 next-key 锁，阻塞其他事务。
- 死锁概率上升：长事务持有锁的时间越长，与其他事务形成死锁的概率越高。
| 事务规模 | 影响行数 | 典型超时时间 | 推荐拆分策略 |
|---|---|---|---|
| 小事务 | < 1000 行 | < 1s | 无需拆分 |
| 中事务 | 1000 - 10000 行 | 1s - 10s | 按主键范围分批 |
| 大事务 | 10000 - 100000 行 | 10s - 100s | 按 1000 行一批 + 游标 |
| 超大事务 | > 100000 行 | > 100s | 禁止单次执行，必须分片 |
4.5 资源争用
资源争用发生在数据库服务器的 CPU、内存、磁盘 I/O 或连接数达到瓶颈时。迁移任务作为“外来负载”，极易与在线业务争抢资源。
缓解策略：使用
SELECT * FROM sys.schema_table_lock_waits 实时查看锁争用；通过 SHOW PROCESSLIST 识别长时间运行的迁移查询；在迁移脚本中引入 throttle 机制，限制每秒处理行数。
4.6 慢查询
慢查询是超时的直接表现，但根源往往在于上述四种原因之一。慢查询本身也会成为新的超时诱因，形成恶性循环。
慢查询的典型特征包括：
- 全表扫描：缺少索引或索引失效，导致扫描行数过大。
- 临时表使用：GROUP BY / ORDER BY 操作在磁盘上创建临时表。
- 函数索引失效：在索引列上使用函数或隐式类型转换。
- 数据倾斜：分区表或分片表中，部分分区数据量过大。
排查命令：开启慢查询日志
SET GLOBAL slow_query_log = ON;，设置 long_query_time = 2（单位秒）。使用 pt-query-digest 分析慢查询日志，定位 TOP N 耗时查询。
4.7 超时原因对比总结
| 原因 | 典型超时范围 | 是否可重试 | 重试策略 | 监控指标 |
|---|---|---|---|---|
| 网络延迟 | 1s - 30s | 是 | 指数退避 + 连接池复用 | 网络 RTT、丢包率 |
| 锁等待 | 10s - 50s | 部分可重试 | 等待锁释放后重试，避免死锁 | 锁等待时间、死锁计数 |
| 大事务 | 30s - 300s | 否（需拆分） | 先拆分事务，再逐批重试 | 事务持续时间、undo 大小 |
| 资源争用 | 5s - 120s | 是 | 降低并发度 + 限流重试 | CPU 使用率、磁盘 IOPS |
| 慢查询 | 2s - 600s | 否（需优化） | 先优化 SQL 或加索引，再重试 | 慢查询日志、扫描行数 |
核心原则：超时原因分析是重试机制设计的基础。对于网络延迟和资源争用，重试是有效的；对于大事务和慢查询，必须先优化再重试，否则重试只会加速系统崩溃。