show processlist 是排查 mysql 迁移卡住的首选命令，需用 show full processlist 并以高权限执行，重点关注 state 列（如 waiting for table metadata lock），并可结合 information_schema.processlist 过滤非空闲连接。
如何实时查看 MySQL 迁移中的活跃进程
迁移卡住时，SHOW PROCESSLIST 是第一个该查的命令。它能立刻告诉你有没有长事务、锁等待或卡在 COPY TO TMP TABLE 的 DDL 操作上。
但默认只显示前 100 行，且普通用户看不到其他用户的线程。所以实际要用：
-
SHOW FULL PROCESSLIST（加FULL防止 SQL 被截断） - 用
root或带PROCESS权限的账号执行 - 重点关注
State列：如Waiting for table metadata lock就是典型阻塞信号 - 配合
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep'可过滤掉空闲连接
mysqldump / mysqlpump 迁移时怎么知道进度
原生命令不输出进度条，但可以通过外部手段估算。关键不是“猜”，而是找可监控的锚点。
-
mysqldump没有内置进度，但加--verbose会打印每个表开始导出的日志，适合小库人工盯 -
mysqlpump支持--watch参数，会输出类似Progress: 124/892 tables completed，但仅限于表级，不含数据行数 - 真正靠谱的方式是查目标库：
SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'target_db'对比源库表数量；再用SELECT TABLE_NAME, TABLE_ROWS FROM information_schema.TABLES粗略比对行数（注意TABLE_ROWS是估算值，InnoDB 不精确） - 别依赖
du -sh查文件大小——.sql 文件写入是流式，磁盘增长滞后于实际导出进度
遇到 “Lost connection during query” 怎么定位是网络还是 SQL 问题
这个错误表面看是连接断了，但根源可能在客户端超时、服务端 kill、或中间件拦截，不能直接重试。
- 先查服务端日志：
tail -f /var/log/mysql/error.log，如果出现Killed thread [id]，说明被KILL命令或wait_timeout终止 - 检查客户端设置：
mysql --connect-timeout=60 --net-read-timeout=3600 --net-write-timeout=3600，尤其net_read/write_timeout默认只有 30 秒，大表导入必炸 - 如果是 mysqldump 导出中断，加
--single-transaction和--skip-lock-tables减少锁竞争，但要注意快照一致性代价 - 用
tcpdump抓包确认是否真有 RST 包发出——如果有，就是网络设备（如负载均衡器）主动断连，和 MySQL 本身无关
从错误日志里快速识别迁移失败的真正原因
MySQL 错误日志里混着启动信息、慢查询、警告和致命错误，直接 grep ERROR 会漏掉关键线索。
- 优先搜具体错误号：
grep "ERROR 1062\|ERROR 1146\|ERROR 1215" /var/log/mysql/error.log，这些是主键冲突、表不存在、外键约束失败的典型码 -
ERROR 2013 (HY000)表示连接丢失，需回溯前 10 行看是否有Aborted connection或Got timeout reading communication packets - 导入 SQL 文件时报错，错误日志里往往只记最后一行。这时要结合客户端输出：比如
mysql -u root db 失败时，终端显示的 <code>ERROR 1054 (42S22) at line 12345才是准确定位点 - 注意日志时间戳时区：系统日志用本地时间，MySQL 日志默认 UTC，对比时别搞反
迁移中最容易被忽略的是权限继承问题——比如用 mysqldump --all-databases 导出后，在新实例执行 mysql ，但没提前创建对应用户或没恢复 <code>mysql.user 表，后续应用连不上却报错在业务 SQL 上。
