备份前必须确认的三个配置项：一是数据库配置是否禁用PDO::ATTR_PERSISTENT，避免mysqldump连接复用失败；二是backup_path目录是否可写，尤其注意runtime目录在nginx或Docker中的权限隔离；三是exec、shell_exec函数是否启用，确保能调用系统mysqldump命令。
备份前必须确认的三个配置项
ThinkPHP 自身不提供数据库备份/恢复功能，得靠第三方扩展或手写逻辑。最常用的是 thinkphp-helper 或自建 DbBackup 类，但无论哪种，都依赖底层 PDO 连接和文件系统权限。先检查：数据库配置是否启用 PDO::ATTR_PERSISTENT？——开启后 mysqldump 命令可能因连接复用失败；backup_path 目录是否可写？默认常设为 runtime/backup/，但 runtime 目录在某些部署环境下被 nginx 用户隔离；是否禁用了 exec、shell_exec？——这是调用系统 mysqldump 的前提，宝塔、Docker 容器环境常默认关闭。
用 mysqldump 命令行备份时的参数陷阱
直接执行 mysqldump 最快，但参数错一个就导出不全或乱码。常见错误是漏掉 --single-transaction，导致高并发下备份数据不一致；或者没加 --default-character-set=utf8mb4，中文字段变成问号；更隐蔽的是没指定 --routines 和 --triggers，存储过程和触发器全丢了。建议固定模板：
mysqldump -u<code>username</code> -p<code>password</code> --host=<code>127.0.0.1</code> --port=<code>3306</code> --single-transaction --routines --triggers --default-character-set=utf8mb4 <code>database_name</code> > <code>/path/to/backup.sql</code>
注意：password 不要明文写在命令里（有安全审计风险），改用 mysql_config_editor 预存登录信息，或通过 PHP 的 proc_open() 传参方式交互输入。
用 PHP 原生 PDO 分表导出避免内存溢出
当单表超 50MB，mysqldump 可能卡死或超时，这时得用 PHP 控制导出节奏。核心思路是：查主键范围 → 分段 SELECT ... INTO OUTFILE 或逐批 fetch → 拼 SQL 文件。关键点：
立即学习“PHP免费学习笔记（深入）”；
- 不用
SELECT * FROM table全量拉取，改用SELECT id, name, ... FROM table WHERE id BETWEEN ? AND ? - 每次 fetch 不超过 1000 行，用
PDO::FETCH_ASSOC避免对象开销 - INSERT 语句手动拼接，字段名用反引号包裹（防关键字冲突），值用
PDO::quote()转义 - 每写入 1 万行就
fflush()一次，否则大文件写到一半崩溃就全丢
别忘了导出前加 SET NAMES utf8mb4 和 SET FOREIGN_KEY_CHECKS=0，不然恢复时外键约束报错。
恢复时忽略 CREATE DATABASE 和权限语句
从生产环境备份恢复到测试库，最常踩的坑是 SQL 文件开头带 CREATE DATABASE `xxx` 或 GRANT 语句——测试库没权限执行，直接中断。解决方法不是手动删，而是用 sed 或 PHP 正则预处理：
sed -i '/^CREATE DATABASE/d; /^GRANT /d; /^FLUSH /d' <code>backup.sql</code>
更稳妥的是在恢复前用 PHP 读取文件，跳过以 CREATE DATABASE、USE 、GRANT 开头的行，再用 PDO::exec() 执行剩余内容。注意：如果备份含视图，需确保目标库已存在所有基表，且 sql_mode 一致，否则 CREATE VIEW 报错。
备份不是“一键完事”，真正麻烦的是跨环境字符集、权限模型、外键顺序这些细节。导出时多看一眼 SHOW CREATE TABLE 输出，比恢复时报错再排查省两小时。
