应使用mysqldump命令行导出：mysqldump -u username -p[password] --single-transaction --skip-lock-tables database_name > backup.sql，避免phpMyAdmin因内存和超时限制导致报错或卡死。
导出超 200MB 的数据库时 phpMyAdmin 直接报错或卡死
默认配置下，phpmyadmin 无法导出大库——它依赖 php 的内存和执行时间限制，且整个导出过程在 web 请求中完成。常见错误包括：maximum execution time of 300 seconds exceeded、allowed memory size of xxx bytes exhausted，或者导出文件为空、只含表结构无数据。
真正可行的解法不是调高 php.ini 参数（治标不治本，还可能拖垮服务器），而是绕过 Web 层，用命令行直连导出：
- 确认服务器有 SSH 访问权限和
mysqldump命令可用（通常 MySQL 客户端已预装） - 用终端登录后执行：
mysqldump -u [username] -p[password] --single-transaction --skip-lock-tables [database_name] > backup.sql
（注意：-p和密码之间**不能有空格**） - 如需压缩节省空间，加管道：
mysqldump -u [username] -p[password] [database_name] | gzip > backup.sql.gz
- 导出完成后，用
scp或 FTP 下载到本地，而非通过 phpMyAdmin 界面下载
导出时加 --single-transaction 是为了不锁表
大型业务库通常不能停写，而默认 mysqldump 会对每个表执行 LOCK TABLES，导致写入阻塞甚至超时失败。加 --single-transaction 可利用 InnoDB 的 MVCC 特性，在事务快照中一致性导出，全程不锁表（仅要求存储引擎为 InnoDB）。
但要注意：
- 该参数对 MyISAM 表无效，会退化为表级锁，导出前先查引擎：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db';
- 如果库中混有 MyISAM 表，且必须保证一致性，可改用
--lock-all-tables，但需接受短时写入中断 -
--skip-lock-tables单独使用不保证一致性，仅避免显式锁，不推荐与--single-transaction冲突使用
phpMyAdmin 界面导出能救急的唯一场景：分表导出 + 关闭“保存为文件”
当完全无法接触服务器命令行（比如纯共享主机），且数据库虽大但单张表不大（如日志表已按月拆分），可尝试在 phpMyAdmin 中逐个导出关键表。
立即学习“PHP免费学习笔记（深入）”；
操作要点：
- 进入对应数据库 → 左侧点击某张表 → 顶部选「导出」→ 格式选
SQL→ 在「输出」区域取消勾选「保存为文件」，改选「显示所有查询」 - 这样导出内容直接渲染在浏览器页面，避开 PHP 文件上传/下载的内存瓶颈（但仅限几百 MB 以内，再大会导致浏览器崩溃）
- 复制页面内容 → 粘贴进本地文本编辑器 → 手动保存为
.sql文件（注意编码选 UTF-8 without BOM） - 务必检查导出内容是否完整：开头有
CREATE TABLE，结尾有大量INSERT，且行数大致匹配SELECT COUNT(*)结果
导出后验证 backup.sql 是否可用比“导出成功”更重要
很多用户以为下载完文件就万事大吉，结果恢复时报错才发现导出中途被截断、字符集错乱、或触发了 PHP 的 output_buffering 自动截断（尤其用界面导出时）。
简单验证方法：
- 用
head -n 20 backup.sql看开头是否有CREATE DATABASE或USE语句；用tail -n 20 backup.sql看结尾是否以;结束，而非被强行截断的半条INSERT - 检查文件大小是否合理：例如一个 500MB 的库，导出 SQL 文件通常在 600–900MB（含文本冗余），若只有 10MB，大概率出问题
- 最可靠方式：在测试环境快速导入一次：
mysql -u [user] -p[pass] [new_db] < backup.sql
，观察有无ERROR 1064或ERROR 1267类报错
真正麻烦的不是导不出，而是导出了一份“看起来成功、实际不可用”的备份文件。
