这是 MySQL 服务未启用 InnoDB 引擎所致,需执行 SHOW ENGINES 确认支持状态,检查并修正配置文件中 skip-innodb 或 disabled_storage_engines 设置,重启 mysqld 后重试导入。
这是 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"
disabled_storage_engines 默认值为空,但若被显式设为包含 InnoDB,需手动清空该配置项mysqld,再尝试 source backup.sql 或 mysql -u root -p db_name
备份文件里不含 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,注意引号和换行转义
--databases 时只导出表结构与数据,不带建库和 USE,这点容易被忽略本质是字符集不一致:备份时用的是 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;
不是网络或权限问题,大概率是 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 权限,会静默失败——需用高权限账号或删掉该行