不能用mysqldump导入tb级数据，因其单线程导出导入慢、传输耗时长、锁表时间久、中间文件膨胀易爆磁盘，且无法满足秒级停机要求；应采用xtrabackup物理备份+主从增量同步+切流组合方案。
TB级别数据没法靠 mysqldump 一次性扛住，必须放弃“导出→传输→导入”单线程逻辑路径，转向物理备份 + 增量同步 + 切流的组合方案。
为什么不能用 mysqldump 导入 TB 级数据？
不是语法错，是现实压垮了它：
-
mysqldump默认单线程导出，1TB 数据在千兆网络下仅传输就可能耗时 3 小时以上；导入更慢，因为要重建索引、触发约束、重放事务 - 导出期间若源库有写入，
--single-transaction只能保证 InnoDB 表一致性，但 DDL（如ALTER TABLE）仍可能破坏快照 - 导入过程锁表时间长，目标库在导入中无法响应业务请求，停机窗口远超分钟级要求
- 中间文件（.sql）体积常比原始数据大 1.5–2 倍，磁盘空间容易爆掉
Percona XtraBackup 是当前最稳的物理迁移起点
它直接拷贝 InnoDB 的 ibdata1 和 .ibd 文件，跳过 SQL 解析层，速度接近磁盘 IO 极限：
- 必须关闭源库或确保无 DDL 操作（XtraBackup 支持热备，但不支持热 DDL）
- 备份命令示例：
xtrabackup --backup --target-dir=/backup/ --user=root --password=xxx - 恢复到目标服务器前，先用
xtrabackup --prepare回滚未提交事务、前滚已提交事务 - 恢复后记得执行
chown -R mysql:mysql /var/lib/mysql/，否则 MySQL 启动失败 - 注意：XtraBackup 不兼容 MySQL 8.0 的默认认证插件（caching_sha2_password），需提前把用户改为
mysql_native_password或升级 XtraBackup 至 8.0+ 版本
主从复制补增量，才是平滑切换的关键
物理备份只能解决“基线数据”，真正实现秒级切换靠的是让目标库持续追上源库的最新变更：
- 备份完成后，立刻在源库执行
SHOW MASTER STATUS，记录File和Position - 在目标库配置
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy，指向备份那一刻的 binlog 位置 - 启动复制：
START SLAVE，监控Seconds_Behind_Master是否稳定归零 - 切流前做一次
FLUSH TABLES WITH READ LOCK（源库），再查SHOW MASTER STATUS记下新位置，等目标库追至此位置后解锁 —— 这一步控制停机窗口在秒级 - 别忽略 relay log 清理：目标库
relay_log_purge=ON必须开启，否则磁盘被 relay 日志撑爆
切流后最容易被忽略的三件事
流量切过去不等于迁移完成，很多故障发生在切换后 1 小时内：
- 应用连接池里的旧连接没断开，还在往源库写数据 —— 必须重启应用或强制清理连接池（如 Druid 的
removeAbandonedOnMaintenance） - 目标库的
innodb_buffer_pool_size没按实际内存重新调优，缓存命中率低导致查询变慢 - 没检查
lower_case_table_names：Linux 源库设为 0，Windows 目标库若设为 1，会导致表找不到（尤其 ORM 自动生成的表名大小写敏感）
