全库恢复是直接导入mysqldump --all-databases生成的SQL文件，覆盖所有库（含系统库），风险高但适用于整实例崩溃；须检查CREATE DATABASE语句、目标库列表及字符集、SQL模式、权限库同步等细节。
全库恢复：直接覆盖所有数据库，风险高但省事
全库恢复本质是把 mysqldump --all-databases 生成的 SQL 文件，原样导入到一个空或已存在的 MySQL 实例中。它不区分库名、不跳过冲突，会重建所有库（包括 mysql、sys 等系统库），并执行其中所有 CREATE DATABASE 和 USE 语句。
- 适用场景：整实例崩溃、误删多个库、灾备环境重建
- 致命风险：若目标实例已有同名业务库，会被
DROP DATABASE（如果备份含--add-drop-database）或建表失败（主键/唯一键冲突）直接中断；系统库覆盖可能导致权限丢失、复制中断 - 必须前置检查：
grep "CREATE DATABASE" backup.sql | head -5确认是否真含所有库；mysql -e "SHOW DATABASES;"对比目标库列表 - 恢复命令示例：
mysql -u root -p （注意：不能加数据库名，否则报错ERROR 1046 (3D000): No database selected）
单库恢复：精准定位+隔离操作，安全但需手动提取
单库恢复不是“从全库备份里挑出一个库”，而是靠 --one-database（或简写 -o）参数让 mysql 客户端**只执行匹配指定库名的 SQL 片段**——它会忽略其他库的 CREATE DATABASE、USE 和建表语句，仅处理目标库的结构和数据。
- 关键前提：全库备份文件必须用
mysqldump --all-databases生成（含完整库边界标记），不能是多个--databases db1 db2拼接的文件 - 常见错误：漏写
--one-database，导致导入时创建了其他无关库；或误在命令末尾加库名（如mysql -u root -p mydb ），此时参数失效，变成全库导入 - 实操建议：先用
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS target_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"显式建库，再执行：mysql -u root -p --one-database target_db - 兼容性注意：MySQL 5.7+ 支持，但 MariaDB 某些旧版本对
--one-database解析不稳定，建议优先用sed -n '/^-- Current Database: `target_db`/,/^-- Current Database: `/p' all.sql | mysql -u root -p target_db替代
为什么不能直接用 grep + source 恢复单库？
很多人试图用 grep -A 1000 "CREATE DATABASE \`mydb\`" all.sql > mydb.sql 提取片段再 source，这极大概率失败——因为 mysqldump --all-databases 的输出中，库与库之间没有严格分隔符，CREATE TABLE 语句可能跨块出现，且 INSERT 数据常被拆成多行，grep 截断会破坏 SQL 语法，导入时报 ERROR 1064 (42000)。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 真正安全的提取方式只有两种：用
--one-database让客户端过滤，或用awk/sed基于-- Current Database:注释块精确切片（需确认备份开启--comments） - 如果备份时没加
--comments，grep "CREATE DATABASE \`mydb\`"只能定位起始位置，无法确定结束位置，不可靠 - 临时补救：用
mysqlbinlog解析 binlog 恢复单库更稳妥，但前提是开启了binlog_format = ROW且日志未过期
恢复前最易忽略的三个细节
无论全库还是单库，以下三点一旦遗漏，90% 的恢复会卡在最后一步：
-
character_set_server不一致：备份时用utf8mb4，恢复时实例默认latin1，会导致中文变问号。务必在导入前执行：mysql -u root -p -e "SET NAMES utf8mb4;"或在命令中加--default-character-set=utf8mb4 - SQL_MODE 差异：线上库开
STRICT_TRANS_TABLES，恢复时关闭，可能跳过字段长度超限等报错，数据静默截断。建议导出时加--set-gtid-purged=OFF --skip-triggers避免 GTID 冲突，导入时加--force忽略非致命错误（慎用） - 权限库未同步：全库恢复会覆盖
mysql库，但新实例的 socket、密码插件可能不兼容旧用户表。单库恢复虽不碰权限库，但若目标库用户不存在，应用连接会报Access denied——需单独执行CREATE USER和GRANT
