PHP调用mysqldump失败主因是权限与路径问题：Web用户无PATH访问权或数据库本地登录权限；须用绝对路径、确认localhost socket权限、设置PATH环境变量、转义参数；热备需--single-transaction与--skip-lock-tables；错误捕获应使用proc_open重定向stderr并设超时；备份文件需唯一命名、校验完整性、压缩在PHP层完成、按策略清理。
PHP调用mysqldump命令失败的常见原因
直接exec()或shell_exec()跑mysqldump却没生成文件？大概率是权限或环境路径问题。Web服务器（如Apache/Nginx）运行的PHP进程通常以www-data或nobody用户身份执行，该用户可能没有mysqldump命令的PATH访问权限，也未必有数据库账号的本地登录权限。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先用
which mysqldump查出完整路径（如/usr/bin/mysqldump），脚本中必须写绝对路径，不能只写mysqldump - 确认MySQL用户允许从
localhost（非127.0.0.1）用密码登录——因为mysqldump -h localhost走的是socket连接，而-h 127.0.0.1走TCP，权限记录可能不一致 - 临时在脚本开头加
putenv('PATH=/usr/bin:/bin');，避免PATH丢失 - 用
escapeshellarg()包裹所有用户输入的参数（如数据库名、用户名），防止命令注入
热备份必须加--single-transaction和--skip-lock-tables
InnoDB表不做事务隔离直接dump，很可能遇到锁表或数据不一致。默认mysqldump会加FLUSH TABLES WITH READ LOCK，这会阻塞写入——不是“热”备份。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
-
--single-transaction是核心：它在开始dump前启动一个一致性快照（REPEATABLE READ事务），全程不锁表，适用于全InnoDB库 -
--skip-lock-tables必须显式加上，否则mysqldump在碰到MyISAM表时仍会尝试锁表（哪怕你库里其实没MyISAM） - 如果库混用引擎，且必须保证MyISAM一致性，就无法真正热备——得接受短时锁表，改用
--lock-all-tables，但这就不是“热”了 - 别加
--master-data=2除非你要做主从；它会执行FLUSH TABLES WITH READ LOCK，破坏热备前提
PHP封装时如何安全捕获错误并控制超时
shell_exec()只返回stdout，stderr被丢弃，dump失败时你看不到具体报错（比如密码错、连不上、磁盘满）。更糟的是，大库dump可能卡住十几分钟，PHP进程无响应。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
proc_open()重定向stderr到pipe，才能拿到真实错误信息，例如2>&1拼在命令末尾还不够，要显式配置descriptor spec - 设置
stream_set_timeout($pipes[2], 300)（假设stderr是第三个pipe），防止读取卡死 - 用
proc_get_status()轮询检查子进程是否超时，结合proc_terminate()主动杀掉僵死的mysqldump - dump完成后立刻用
md5_file()校验SQL文件是否为空或截断（常见于磁盘满或中断）
备份文件命名与清理策略要防覆盖和堆积
用固定文件名（如backup.sql）会导致新备份覆盖旧备份；放任不清理又会撑爆磁盘。时间戳看似合理，但并发执行时可能撞名（尤其cron每分钟跑一次）。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 文件名包含
date('Ymd_His') . '_' . uniqid('', true)，确保唯一性 - 压缩必须在PHP里完成（
gzencode(file_get_contents($sqlfile))），不要依赖mysqldump | gzip管道——出错时难定位是dump失败还是gzip失败 - 清理逻辑单独写成函数，按修改时间保留最近7天+最近5个文件（避免某天高频备份导致删光）
- 把备份目录设为Web不可访问路径（如
/var/backups/myapp/），绝不要放在public_html下
真正麻烦的不是调通命令，而是当备份跑了47分钟突然因磁盘满失败时，你得知道它卡在哪一步、有没有残留临时文件、下次会不会重复尝试同一张坏表——这些都得在proc_open的状态检查和信号处理里埋点。
