能直接恢复，不用先解压再导入——只要压缩格式是 gzip 或 bzip2，且备份时用的是 mysqldump 生成的纯 sql 流，就可以管道直通恢复；因 gzip 非 zip 格式，windows 双击解压会出错，且落地解压再导入既慢又占空间。
能直接恢复，不用先解压再导入——只要压缩格式是 gzip 或 bzip2，且备份时用的是 mysqldump 生成的纯 SQL 流，就可以管道直通恢复。
为什么不能直接用 unzip / 7z 解压后再 mysql -e？
因为常见错误是把 .sql.gz 当成普通 zip 包双击解压，结果得到一个空文件或乱码——gzip 压缩的不是 ZIP 格式，Windows 资源管理器不识别；更关键的是，哪怕手动解出 .sql，再用 mysql -u root -p db 恢复，中间多一次磁盘 I/O 和临时文件写入，对大库（>500MB）明显拖慢速度，还占两倍空间。
-
.sql.gz和.sql.bz2是流式压缩，必须用对应解压命令配合管道传递给mysql -
.zip或.tar包裹的 SQL 文件（比如运维打包发来的backup.zip）才需要先解压 - 确认格式：运行
file backup.sql.gz，输出含gzip compressed data才适用本文方法
gzip 压缩包怎么一行命令恢复？
最常用场景：Linux/macOS 下恢复 backup.sql.gz 到指定库。核心是让 gunzip 解压输出直接喂给 mysql，不落地。
- 基础命令：
gunzip - 如果密码已配置在
~/.my.cnf，可省略-p：gunzip - 恢复到远程库：
gunzip - 加
-v看进度（仅限小文件）：gunzip -c backup.sql.gz | mysql -u root -p mydb（-c强制输出到 stdout）
bzip2 压缩包恢复要换命令
bzip2 压缩率比 gzip 高约 10%–15%，但解压慢；恢复命令结构类似，只是工具名和参数不同。
- 标准恢复：
bunzip2 - 等效写法：
bzcat backup.sql.bz2 | mysql -u root -p mydb（bzcat即bunzip2 -c） - 注意：
bunzip2默认会删除原文件，加-k保留：bunzip2 -k - Windows 下没有原生命令，需装
cygwin或用 WSL；PowerShell 不支持直接管道传二进制流，别硬试
恢复失败常见卡点
看似一行命令，实际容易栽在权限、字符集、SQL 兼容性上。
- 报错
ERROR 1045 (28000): Access denied：检查mysql客户端连接权限，不是mysqldump备份时的用户权限 - 报错
ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'：MySQL 8.0 备份在 5.7 恢复，删掉 SQL 文件头的DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci或升级目标库 - 恢复中途停住没报错：大概率是 SQL 文件里有
CREATE DATABASE语句，但目标库已存在，加--force参数跳过：gunzip - 中文变问号：备份时没指定
--default-character-set=utf8mb4，恢复时也得保持一致，否则管道流默认走 latin1
真正麻烦的不是命令本身，而是压缩包来源不明时——你得先 gunzip -t 或 bunzip2 -t 校验完整性，再 head -n 20 看前几行是不是 CREATE TABLE，否则一跑就是几小时，失败才发现文件根本不对。
