mysqldump报错默认不写入日志，需显式重定向stderr（如2>dump.err）才能捕获错误；常见错误包括权限不足、锁超时、表名非法、磁盘满等；--log-error无效于客户端错误，脚本中应检查$?并校验变量。
mysqldump 报错时日志里看不到具体错误？
默认情况下 mysqldump 错误直接输出到 stderr，不写入日志文件——你看到的“空日志”或“只有成功语句”，大概率是因为没捕获 stderr。要真看报错，必须显式重定向：
mysqldump -u root -p db_name 2>&1 > backup.sql或者更稳妥地分开记录：
mysqldump -u root -p db_name > backup.sql 2> dump.err。否则
dump.err 为空，backup.sql 可能是截断的半成品，还带不了上下文。
常见 dump.err 中的关键错误信息怎么读
打开 dump.err 后别从头扫，先搜这几类关键词：
-
Access denied for user：账号没权限，重点查SELECT、LOCK TABLES、SHOW VIEW权限，不是光有USAGE就行 -
Couldn't execute 'SELECT ...': Lock wait timeout exceeded：表被长事务锁住，不是加--single-transaction就能绕过，得确认 MySQL 版本支持（5.6+）、引擎是 InnoDB，且没在执行 DDL -
Unknown table 'xxx' in information_schema：库名或表名含特殊字符（比如中划线、空格），必须用反引号包裹，但mysqldump自动加的反引号有时会失效，可试加--skip-quote-names再手动处理 -
Got errno 32 on write：磁盘满或backup.sql所在目录不可写，注意检查df -h和父目录权限，不是 MySQL 用户权限问题
为什么加了 --log-error 还没日志？
mysqldump 的 --log-error 参数只控制「服务端错误日志」的路径，它不接管客户端自身的报错（比如连接失败、参数错误、权限拒绝）。这个参数实际作用非常有限，日常排查基本用不上。真正该盯的是命令行重定向结果，而不是依赖它。另外，如果用了 --defaults-extra-file 指定配置文件，记得检查该文件里有没有意外覆盖了 user 或 password，这类静默覆盖会导致 Access denied 却不提示哪行配置出问题。
备份脚本里如何让错误立刻中断并暴露出来
别靠肉眼翻日志，脚本里加两行就稳得多：
- 用
set -e让任意命令失败直接退出（注意兼容性，部分老 shell 需用set -o errexit） - 执行后立刻检查
$?：mysqldump -u $USER -p$PASS mydb > out.sql 2> err.log<br>if [ $? -ne 0 ]; then echo "Dump failed"; cat err.log; exit 1; fi
- 关键点：
mysqldump成功时返回 0，但部分错误（如部分表导出失败）可能仍返回 0 —— 此时得靠err.log是否为空或 grep 错误关键词来兜底
最常被忽略的是：脚本里用了变量传密码，但变量为空时 mysqldump 会交互式等输入，导致卡住；务必在执行前校验 [ -z "$PASS" ] 并提前报错。
