说到ThinkPHP数据备份，mysqldump是绕不开的利器。框架本身不内置完整的备份逻辑，但和系统级工具配合起来非常顺手。千万别想着靠Db::query()拼SQL去搞定生产环境的备份——字段类型丢失、BLOB截断、事务不一致、缺少触发器存储过程…这些坑一个比一个深。
mysqldump是ThinkPHP生产环境数据备份唯一推荐方案，因其支持事务一致性（--single-transaction）、完整对象导出（--routines --triggers --events）、二进制安全（--hex-blob）及编码可控（--default-character-set=utf8mb4），而手动拼SQL存在类型错乱、BLOB截断、无事务、内存溢出等严重隐患。
为什么不用ThinkPHP自己拼SQL备份
手动遍历表 + SHOW CREATE TABLE + SELECT *拼INSERT语句，看起来可控，实际暗藏的风险可不小：
- 遇到
TINYINT(1)或ENUM字段，Db::select()返回布尔或字符串，INSERT时类型直接错乱 TEXT/MEDIUMBLOB类型字段含换行、引号、\0字节，addslashes()根本不顶用，到头来不是SQL语法错误就是数据截断- 没显式开启事务，备份中途表被写入，导出的数据和结构对不上（尤其非InnoDB表）
- 不导出
ROUTINES、TRIGGERS、EVENTS，恢复后发现业务逻辑异常，查半天找不到原因 - 大表导出内存直接爆掉——
Db::select()全量加载进PHP内存，100万行基本就挂了
用mysqldump命令行必须加的关键参数
直接调用mysqldump是唯一推荐的方案，但参数漏一个都可能翻车：
--single-transaction：InnoDB表必备，保证备份瞬间一致性，不锁表；MyISAM表必须配--lock-tables，否则数据错位--routines --triggers --events：导出存储过程、触发器、事件——很多权限管理、定时任务逻辑就藏在这里--hex-blob：把BLOB/BINARY字段转为十六进制字符串，避免二进制污染SQL文件--set-gtid-purged=OFF：MySQL 5.7+默认开启GTID，不关掉会导致导入时报GTID_PURGED can only be set when @@GLOBAL.GTID_MODE = ON--default-character-set=utf8mb4：显式指定编码，防止建表语句里漏掉CHARSET，导入时乱码
完整命令示例：mysqldump -h127.0.0.1 -P3306 -uroot -p'pass' --single-transaction --routines --triggers --hex-blob --set-gtid-purged=OFF --default-character-set=utf8mb4 mydb > /runtime/backup/mydb_20260421.sql
ThinkPHP命令行备份类怎么写才安全
用think console写备份命令，比在控制器里裸跑exec()更可控、可调度。关键点不是“能不能跑”，而是“跑崩了有没有反馈”：
- 必须用
escapeshellarg()包裹所有变量（$host、$user、$pass、$file），否则密码含$或空格，直接命令注入 - 不能只看
$code === 0，mysqldump出错时可能仍返回0，要检查输出内容是否含Warning:或ERROR - 备份目录权限要设对：
mkdir($dir, 0755, true)，不能0777——/runtime/backup被web可读，等于把数据库裸奔给黑客 - 文件名必须含时间戳且唯一：
$name . '_' . date('Ymd_His') . '.sql'，避免crontab多次运行覆盖 - 建议加
umask(0022)开头，防止生成的.sql文件权限过于宽松（如0666）
恢复时最容易忽略的三件事
备份难，恢复更难——90%的恢复失败不是命令写错，而是环境细节没对齐：
- 目标库必须已存在，且字符集与原库一致（
CREATE DATABASE xxx CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci），否则中文变? - 导入前先清空再导入？别干这事。直接
mysql -u... -p... db_name < file.sql，DROP TABLE IF EXISTS语句已在dump文件里 - 如果备份用了
--single-transaction，恢复时不要加--force，否则会跳过建表失败等致命错误，静默丢数据 - 导入大文件前，临时调高MySQL配置：
max_allowed_packet=512M、innodb_log_file_size=256M，不然卡在半途报Packets larger than max_allowed_packet are not allowed
真正麻烦的永远不是“怎么备份”，而是“备份出来的文件，能不能在另一台机器上一模一样地还原”。字符集、SQL mode、GTID、binlog_format，甚至MySQL版本小版本差异，都可能让.sql文件导入失败或行为偏移。生产环境务必定期验证备份可用性——解压、导入、查几条关键数据，比什么都强。
