导出时必须选中“mariadb”兼容模式,手动在格式下拉菜单选择mariadb而非mysql,以避免sql_mode不兼容、函数差异及存储引擎报错;确认phpmyadmin≥4.9,10.3+版本勾选十六进制二进制字段,禁用create database语句并手动建库指定字符集,慎用压缩与分卷,导入前检查engine、charset、row_format三项兼容性。
导出时必须选中“mariadb”兼容模式
phpmyadmin 默认导出格式面向 mysql,直接导出再导入 mariadb 可能触发 sql_mode 不兼容、函数不识别(如 json_extract 行为差异)或存储引擎报错(如 aria 表被强制转成 innodb)。关键动作是在导出页顶部的「格式」下拉菜单里,**手动选中 mariadb 而非 mysql** —— 这会自动启用适配 mariadb 的 sql 语法和注释标记。
常见错误现象:导出文件开头是 /*!40101 SET ... */ 这类 MySQL 版本标识,而 MariaDB 5.5+ 实际解析时可能跳过或误判;选对 MariaDB 后,头部会变成 /*!100000 SET ... */ 或更宽松的兼容标记。
- 导出前确认 phpMyAdmin 版本 ≥ 4.9(旧版无此选项,需升级)
- 若目标 MariaDB 是 10.3+,勾选
Use hexadecimal for binary fields避免 BLOB 字段乱码 - 不要勾选
Disable foreign key checks—— MariaDB 导入时默认已处理,手动加反而可能干扰事务恢复
结构导出要禁用“创建数据库”语句
phpMyAdmin 导出时若勾选 CREATE DATABASE,生成的 SQL 里会含 CREATE DATABASE `xxx` 和 USE `xxx`。但 MariaDB 中该库若已存在且字符集/校对规则不同(比如原库是 utf8mb4_unicode_ci,新环境默认是 utf8mb4_general_ci),导入会直接失败并报错 #1007 - Can't create database 'xxx'; database exists 或更隐蔽的校对冲突。
实操建议:在「导出」→「格式特定选项」里,取消勾选 Add CREATE DATABASE / USE statement。你只需确保目标库已手动创建好,且字符集与源库一致:
- 查源库字符集:
SHOW CREATE DATABASE `your_db`; - 建目标库时显式指定:
CREATE DATABASE `your_db` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 导出文件里保留
CREATE TABLE和INSERT即可,无需数据库级语句
数据导出慎用“压缩”和“分卷”功能
phpMyAdmin 内置的 gzip 或 bzip2 压缩导出,在 MariaDB 命令行导入时无法直接使用:mysql -u user -p db_name 会报错语法错误,因为 mysql 客户端不支持解压。必须先解压再导入,徒增步骤且易出错。
分卷导出(Split into files)也容易引发问题:各分卷间事务不连续,INSERT 语句被硬切开,导入时可能卡在中间卷,或因缺少 COMMIT 导致锁表时间过长。
- 导出格式选
SQL,编码选utf8mb4,压缩留空(即不压缩) - 大库(>100MB)改用命令行导出:
mysqldump --databases your_db --single-transaction --routines --triggers --set-gtid-purged=OFF | gzip > dump.sql.gz,再用zcat dump.sql.gz | mysql -u user -p db_name - 若必须用 phpMyAdmin 分卷,请确保每卷以完整
INSERT语句结尾,检查最后一行是否为);而非截断的逗号
导入前手动检查三处关键兼容项
即使导出设置全对,MariaDB 对某些 MySQL 语法仍更严格。导入前快速扫一眼导出文件,比等报错再排查快得多:
- 搜
ENGINE=InnoDB:MariaDB 10.2+ 默认引擎是InnoDB,但若原表用了MyISAM,需手动替换成ENGINE=Aria或删掉整段(MariaDB 会按默认引擎建) - 搜
DEFAULT CHARSET=latin1:MariaDB 通常要求utf8mb4,替换为DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - 搜
ROW_FORMAT=COMPRESSED:MariaDB 的InnoDB不支持该格式,删掉整段或改为ROW_FORMAT=DYNAMIC
这些点看似琐碎,但漏掉任意一个,都可能导致导入停在第 1 行,报错信息还藏在几百行日志里——真正卡住人的从来不是大方向,而是这种导出器默认塞进去、又没人翻的隐性语法。
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











