我之前也遇到过一模一样的情况——脚本直接在浏览器或者命令行跑完全正常，一丢给crontab就罢工，大概率是环境差异或者权限/路径的问题，咱们一步步来排查解决：

1. 先锁定MySQL命令的路径问题 #

crontab运行时的环境变量PATH比普通用户登录后的PATH要精简得多，很可能找不到mysql命令。你可以先在命令行里执行：

which mysql

得到类似/usr/bin/mysql的完整路径，然后把PHP脚本里的mysql替换成这个绝对路径，比如：

exec("/usr/bin/mysql --user='username' --host='host' --password='password' --database='db' --execute='select * from table'", $output, $return);

2. 检查文件权限与路径 #

• 确保crontab运行的用户（一般是你编辑crontab的当前用户，或者root）对/Path_to_file/file.txt有写入权限。可以先手动调整权限：

  chmod 664 /Path_to_file/file.txt
  

  或者检查父目录的权限是否允许创建/修改文件。
• 脚本里所有路径必须是绝对路径，crontab的工作目录是用户的家目录，不是脚本所在目录，千万别用相对路径。

3. 排查MySQL连接的隐藏问题 #

• 如果你平时直接运行脚本时依赖了用户家目录的.my.cnf配置文件（比如里面存了用户名密码），crontab运行时可能加载不到这个文件。可以在exec命令里显式指定：

  exec("/usr/bin/mysql --defaults-extra-file=/home/your_username/.my.cnf --database='db' --execute='select * from table'", $output, $return);
  

• 另外检查远程数据库的IP白名单：直接运行脚本时用的是服务器的公网IP，但crontab执行时会不会走了内部IP？确保数据库允许当前服务器的所有合法IP访问。

4. 开启日志排查错误 #

crontab默认不会输出任何错误信息，这给排查带来很大麻烦。修改你的crontab配置，把输出和错误重定向到日志文件：

06 13 * * * /usr/bin/php /Path_to_php_script/file.php >> /var/log/cron_mysql_script.log 2>&1

同时在PHP脚本里增加错误处理，记录exec的执行状态：

exec("/usr/bin/mysql --user='username' --host='host' --password='password' --database='db' --execute='select * from table'", $output, $return);

// 记录执行结果到日志
$logPath = "/Path_to_logs/script_exec.log";
if ($return !== 0) {
    $logContent = date("Y-m-d H:i:s") . " 脚本执行失败，返回码：{$return}，输出信息：\n" . implode("\n", $output) . "\n\n";
    file_put_contents($logPath, $logContent, FILE_APPEND);
} else {
    file_put_contents("/Path_to_file/file.txt", $output[0]);
}

这样运行后查看日志，就能清楚知道是MySQL命令执行失败，还是文件写入出问题了。

5. 验证PHP路径是否正确 #

虽然你crontab里写了/usr/bin/php，但还是确认一下这个路径是否正确：

which php

如果输出的路径和crontab里的不一致，替换成正确的绝对路径。

内容的提问来源于stack exchange，提问作者Ploiplund