冷备份恢复MySQL必须停服务、版本对齐、权限一致，否则启动必失败；根本原因是mysqld进程未完全停止、主版本号不匹配或属主非mysql:mysql，导致报错“Table 'xxx' doesn't exist”或“InnoDB: Unable to lock ./ibdata1”。
冷备份物理文件恢复 MySQL，本质是直接替换数据目录，不是“导入”，所以必须停服务、版本对齐、权限一致，否则启动必失败。
为什么 mysqld 启动报错 Table 'xxx' doesn't exist 或 InnoDB: Unable to lock ./ibdata1
这是最常见现象，根本原因不是文件没拷对，而是三个条件没同时满足：
- MySQL 服务进程必须完全停止（
systemctl stop mysqld或kill -9确认无残留） - 本地 MySQL 版本主版本号（如
5.7.x或8.0.x）必须与源库一致；8.0.33恢复到8.0.28通常可行，但跨大版本（如5.7 → 8.0）绝对不行 - 数据文件属主必须是运行 MySQL 的用户（通常是
mysql:mysql），用chown -R mysql:mysql /var/lib/mysql修正
如何安全替换 ibdata1、ib_logfile* 和表空间文件
物理冷备恢复不是只拷 .ibd 文件，InnoDB 共享表空间和日志文件也必须一并替换，否则会因元数据不一致导致崩溃：
- 先清空目标数据目录（如
/var/lib/mysql），但保留mysql子目录（含系统库）——除非你确认要全量覆盖 - 把备份里的
ibdata1、ib_logfile0、ib_logfile1、mysql/、performance_schema/、sys/和业务库目录全部复制过去 - 若源库启用了
innodb_file_per_table=OFF，所有表数据都在ibdata1里，此时必须完整替换该文件，不能只拷单个.ibd - 检查
my.cnf中innodb_log_file_size是否与备份时一致，不一致会导致启动失败，需先删日志文件再启动（MySQL 会自动重建）
云数据库下载的 .xb 文件怎么解压还原
腾讯云、阿里云等导出的物理备份是 Percona XtraBackup 打包的 .xb 文件，不能直接解压，必须用配套工具链：
- 安装
percona-xtrabackup-80（MySQL 8.0）或percona-xtrabackup-24（MySQL 5.7），注意版本严格对应 - 先用
xbstream -x -C /data/backup 解包，得到一堆 <code>.qp文件 - 再用
xtrabackup --decompress --target-dir=/data/backup解压所有.qp文件 - 最后执行
xtrabackup --prepare --target-dir=/data/backup回滚未提交事务、前滚已提交事务，生成一致性快照 - 停掉本地 MySQL，清空数据目录，
cp -r /data/backup/* /var/lib/mysql/，再改权限、启动
最容易被忽略的是 --prepare 步骤：跳过它直接拷贝，MySQL 启动后大概率 crash，因为备份时可能有未刷盘的事务。这步没有日志输出，但必不可少。
