这是 MySQL 服务未启用 InnoDB 引擎所致，需执行 SHOW ENGINES 确认支持状态，检查并修正配置文件中 skip-innodb 或 disabled_storage_engines 设置，重启 mysqld 后重试导入。
mysqldump 备份文件导入时提示 “Unknown storage engine ‘InnoDB’”
这是 MySQL 服务未启用 InnoDB 引擎的典型表现，常见于精简版 MySQL 或容器中未正确初始化的实例。不是备份文件损坏，而是目标库缺失关键存储引擎支持。
- 执行
SHOW ENGINES;查看当前可用引擎，确认InnoDB行的Support列是否为YES或DEFAULT - 检查配置文件（如
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf），确保没有出现skip-innodb或disabled_storage_engines = "InnoDB" - 若使用 MySQL 8.0.13+，
disabled_storage_engines默认值为空，但若被显式设为包含InnoDB，需手动清空该配置项 - 修改后重启
mysqld，再尝试source backup.sql或mysql -u root -p db_name
还原时报错 “ERROR 1046 (3D000): No database selected”
备份文件里不含 USE database_name; 语句，或导入时未指定目标库，MySQL 不知道把数据写到哪去。
- 用
head -20 backup.sql | grep 'USE '检查备份头是否有数据库选择语句；若无，不能直接mysql - 要么在导入前手动创建库并选中：
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;"
，再执行mysql -u root -p mydb < backup.sql
- 要么用
sed在备份开头注入 USE 语句（仅限单库备份）：sed -i '1s/^/USE mydb;\n/' backup.sql
，注意引号和换行转义 - mysqldump 默认不加
--databases时只导出表结构与数据，不带建库和 USE，这点容易被忽略
还原后中文乱码或报错 “Incorrect string value: '😊'”
本质是字符集不一致：备份时用的是 utf8mb4，但目标库/表/连接默认是 utf8（MySQL 中的 utf8 实为阉割版，最多 3 字节），导致 emoji 等 4 字节字符失败。
- 检查备份文件头：搜索
CHARSET=或DEFAULT CHARSET=，确认是否为utf8mb4 - 还原前确保目标库已按
utf8mb4创建：CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
- 连接参数必须显式指定字符集：
mysql --default-character-set=utf8mb4 -u root -p mydb < backup.sql
，否则客户端可能仍用latin1或旧utf8 - 若表已存在且字符集不对，不能仅靠
ALTER DATABASE，需逐表执行：ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
mysql 命令行还原卡住、无响应或中途退出
不是网络或权限问题，大概率是 SQL 文件含大 BLOB、超长 INSERT 或非标准语法（如带 /*+ … */ 优化器提示），触发了客户端缓冲限制或语法解析异常。
- 先用
tail -n 50 backup.sql看末尾是否完整（有COMMIT;、无截断），再用grep -n "INSERT INTO" backup.sql | head -5检查前几条 INSERT 是否格式正常 - 跳过注释和空行后再导入，减少解析负担：
grep -v "^--" backup.sql | grep -v "^$" | mysql --default-character-set=utf8mb4 -u root -p mydb
- 对超大文件，改用
mysqlimport或分块导入（用split -l 5000 backup.sql chunk_后循环执行），避免单次内存溢出 - 若含
SET SESSION sql_log_bin=0等语句，而用户无SUPER权限，会静默失败——需用高权限账号或删掉该行
