cron执行MySQL带子查询DELETE语句不生效问题排查

针对脚本手动执行正常、cron调度执行DELETE不生效的问题，按以下步骤排查，优先获取错误日志，再对应修复高频问题：

第一步：先捕获完整错误输出 #

绝大多数cron执行异常都是因为没有捕获输出，看不到具体报错。

• 先修改脚本中执行MySQL的逻辑，把标准输出、标准错误都重定向到固定日志文件，修改后的执行行参考：

echo $SQL | /usr/bin/mysql --user=$MYSQL_USER --host=$MYSQL_HOST --password=$MYSQL_PASS $MYSQL_DB >> /data/logs/cpm_clean.log 2>&1

• 同时修改crontab里的任务配置，把任务本身的输出也追加到同一个日志，参考配置（每天凌晨2点执行的示例）：

0 2 * * * /opt/scripts/clean_cpm_dup.sh >> /data/logs/cpm_clean.log 2>&1

等下次任务触发后直接看日志里的报错，就能直接定位根因，不用盲目试错。

高频故障点及修复方案 #

• 密码传递异常：当前脚本通过命令行明文传MySQL密码，如果密码包含$、&、!、空格这类特殊字符，cron使用的非交互shell会对特殊字符做解析转义，导致密码传递错误，连接数据库失败。部分高版本MySQL默认会拦截命令行传密的请求，直接报错。
  修复方式：在执行cron任务的用户家目录创建权限为600的.my.cnf文件，写入数据库连接配置：

  [client]
  user=对应数据库账号
  password=对应数据库密码
  host=数据库地址
  database=目标库名
  

  之后脚本里的mysql命令直接写/usr/bin/mysql即可，不需要再带连接参数，彻底规避特殊字符解析、传密被拦截的问题。
• 表路径/数据异常：手动在MySQL控制台执行SQL时，默认处于你手动选中的库下，cron建立连接时如果库参数传递异常、或者duplicate_questions_id表是你手动执行时提前生成的临时表、cron执行时该表为空/不存在/在其他库下，都会导致删除操作匹配不到数据。
  修复方式：SQL中所有表名前加上库名前缀，同时子查询明确写查询id字段（虽然当前表只有id字段，避免后续表结构变更报错），修改后的SQL为：

  delete from 你的库名.CPM_QUESTIONS WHERE ID IN (select id from 你的库名.duplicate_questions_id);
  

  如果duplicate_questions_id是每次删除前需要临时生成的表，必须把生成该表的逻辑写到同一个脚本里，不要依赖手动提前生成。
• 执行用户权限不匹配：手动执行脚本用的是你当前登录的用户，cron执行任务时用的是配置crontab的对应用户，两个用户的权限可能不一致：可能没有MySQL客户端执行权限、没有脚本/日志目录的读写权限、甚至没有访问数据库的网络白名单权限。
  排查方式：先通过crontab -l -u 用户名确认任务所属用户，再su到该用户下，手动进入脚本所在目录执行一次脚本，复现问题后针对性补权限即可。
• PATH路径不匹配：虽然脚本里写了PATH变量，但如果MySQL实际安装路径不在你配置的PATH列表里（比如很多编译安装的MySQL在/usr/local/mysql/bin目录下），cron环境下会找不到mysql命令导致执行失败。
  排查方式：在脚本开头加一行which mysql >> /data/logs/cpm_clean.log，执行后看日志是否能输出mysql的完整路径，不能的话就把MySQL的bin目录补到PATH配置里，或者直接在脚本里写mysql命令的绝对路径。

脚本优化点 #

• 脚本中定义的TODAY变量未被使用，可以删除避免冗余。
• 脚本结尾的echo语句重复写了at，把at at ${END_TIME}改成at ${END_TIME}即可。
• 建议在执行DELETE前先加一行查询，把待删除的记录数打到日志里，方便后续审计、避免误删。

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