虽然 phpMyAdmin 3.x 早已停止官方维护，但在许多老旧服务器上——比如运行 CentOS 6 搭配 PHP 5.4 的环境——你仍然会经常遇到它。对于这类老版本工具，用来执行基础数据库导出任务尚可，但有几个关键限制必须绕过，否则核心业务数据可能就在无声无息中丢失。
导出前，先确认 max_allowed_packet 和 post_max_size 是否足够大
phpMyAdmin 3.x 是通过 HTTP POST 提交导出请求的，整个 SQL 文件会被打包在表单中发出。一旦数据库体积超过 2–3 MB，大概率会触发 413 Request Entity Too Large 错误，或者页面直接空白——这时往往不是 phpMyAdmin 崩溃，而是 Web 服务器（Nginx 或 Apache）或 PHP 直接拦截了这个超大请求体。
因此，动手之前请先检查以下几个配置项：
php.ini中的post_max_size至少调整到128M，upload_max_filesize也需要同步调高（虽然不涉及上传，但导出逻辑也复用此配置）。- 如果使用 Apache，别忘了同步调整
LimitRequestBody；如果使用 Nginx，则检查client_max_body_size。 - 修改完配置后，必须重启 Web 服务，仅 reload 无法生效。
别图省事，选择“自定义”导出，并勾选 CREATE DATABASE 和 DROP TABLE
3.x 版本中的“快速导出”选项虽然看起来省事，但会跳过数据库创建语句。导出的 .sql 文件里既没有 CREATE DATABASE IF NOT EXISTS `xxx`，也没有 USE `xxx`。直接拿到新环境导入，很容易因为目标库不存在或当前库不匹配而报错 No database selected。
正确的做法是：
- 进入导出页面后，不要点击“快速”，务必选择“自定义”。
- 在“对象创建选项”区域，记得勾选
ADD CREATE DATABASE / USE statement和ADD DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT statement。 - 如果业务中还使用了存储过程或事件，必须手动勾选
ROUTINES和EVENTS——默认不会导出，很容易被忽略。
字符集必须显式指定为 utf8mb4，不要依赖默认值
phpMyAdmin 3.x 默认的字符集是 utf8（即 MySQL 的 utf8，仅支持 3 字节 UTF-8）。一旦遇到 emoji 表情或四字节的生僻汉字，就会被截断或变成问号。如今业务库基本都使用 utf8mb4，导出时如果不显式声明，数据就会静默丢失。
在“自定义导出”页面，找到“导出”区域，选择 Custom 后展开“格式-specific options”，将 Character set of the file 显式改为 utf8mb4。同时，确认“数据创建选项”中的 Enclose table and column names with backquotes 已勾选，以避免关键字冲突。
大库（>50MB）别硬扛，用 mysqldump 配合 phpMyAdmin 生成命令
即使将所有限制都调高，phpMyAdmin 3.x 在导出百兆级数据库时，仍可能因 PHP 的 max_execution_time 超时、内存溢出，或浏览器断开连接而失败。此时，它唯一可靠的作用反而是帮你生成一条安全可用的 mysqldump 命令。
操作步骤很简单：
- 在 phpMyAdmin 3.x 的导出页面中填好所有选项（字符集、结构+数据、ROUTINES 等都勾上），但先不要点击执行。
- 滚动到底部，找到那行灰色小字提示：
Command to be executed:，后面就是一条完整的mysqldump命令。 - 复制这条命令，SSH 登录到服务器，在终端中粘贴执行，并将输出重定向到文件。例如：
mysqldump -hlocalhost -uuser -p'pass' --routines --triggers --events dbname > backup.sql。 - 这样导出的文件可以直接用于恢复，而且完全没有超时风险。
真正麻烦的并非操作步骤，而是 3.x 这个版本会在不报错的情况下静默丢数据：例如没勾 ROUTINES，它就真的不导出；字符集设置错误，它就默默截断。因此，导出之后务必用 head -n 20 backup.sql 检查开头是否有 CREATE DATABASE 和 DEFAULT CHARSET = utf8mb4，再用 grep -c 'INSERT INTO 确认数据行数是否合理。不要等到导入失败时，才回头去排查。
