mysql命令行备份需用mysqldump --single-transaction --routines --triggers db_name | gzip > /backup/db_name_$(date +\%y\%m\%d_\%h\%m).sql.gz，依赖~/.my.cnf（chmod 600）免密，全路径调用命令，重定向stderr，并用find ... -mtime +7 -delete自动清理旧备份。
MySQL命令行备份命令怎么写才可靠？
直接用 mysqldump 备份，但别只写 mysqldump -u root -p db_name > backup.sql —— 这样会卡在交互式密码输入，无法用于定时任务。必须用配置文件或参数绕过密码提示。
- 推荐方式：把账号密码写进
~/.my.cnf（Linux/macOS）或%USERPROFILE%\my.cnf（Windows），并设权限为600（Linux/macOS 执行chmod 600 ~/.my.cnf），内容如下：
[client] user = backup_user password = your_secure_password host = localhost
- 然后执行备份命令：
mysqldump --single-transaction --routines --triggers db_name | gzip > /backup/db_name_$(date +\%Y\%m\%d_\%H\%M).sql.gz -
--single-transaction对 InnoDB 表保证一致性，不锁表；--routines和--triggers确保存储过程和触发器也被导出 - 务必用
gzip压缩，否则几天就撑爆磁盘；日期格式里的\%要转义，否则 shell 会报错
cron 定时任务为什么总失败？
cron 环境变量和当前 shell 不一样，PATH 很窄，mysqldump 或 gzip 极可能找不到。别假设它知道你的 /usr/local/bin。
- 在 crontab 里显式写全路径：用
which mysqldump和which gzip查到真实路径，例如/usr/bin/mysqldump和/bin/gzip - crontab 条目示例（每天凌晨2点）：
0 2 * * * /usr/bin/mysqldump --single-transaction mydb | /bin/gzip > /backup/mydb_$(/bin/date +\%Y\%m\%d).sql.gz - 务必重定向
stderr到日志，加2>> /var/log/mysql_backup.log，否则失败了你也看不到错误 - 测试时先用
run-parts或手动执行整条命令，确认无报错再扔进 cron
备份文件怎么自动清理才不占满磁盘？
没人清理的备份比没备份还危险——磁盘写满会导致 MySQL 挂掉。
- 加一行清理命令，保留最近7天：
find /backup -name "mydb_*.sql.gz" -mtime +7 -delete - 不要用
-exec rm {} \;，-delete更高效且原子 - 把它和备份命令用
&&连起来（确保备份成功才清理），或单独起一行 cron，但时间错开5分钟避免并发冲突 - 注意
find的-mtime +7是“超过7天”，不是“第7天”，别误删当天备份
备份恢复时常见哪些坑？
备份只是第一步，恢复失败才是真正灾难。最常栽在字符集和 SQL 模式上。
- 导出时加上
--default-character-set=utf8mb4，尤其当库含 emoji 或四字节 UTF-8 字符 - 导入前先检查目标库的
sql_mode，若备份时是宽松模式（如NO_AUTO_CREATE_USER已废弃），而目标 MySQL 8.0 默认严格，会报错；可在导入命令开头加SET sql_mode='';或临时设置 - 恢复命令别漏
mysql -D db_name —— <code>gunzip -c backup.sql.gz | mysql -D db_name才对，直接重定向.gz文件会失败 - 小库可本地测，大库建议先用
head -n 100 backup.sql.gz | gunzip -c看开头是否含CREATE DATABASE和正确字符集声明
真正麻烦的不是写命令，而是备份后从不验证、不模拟恢复、不监控磁盘空间——这些环节一断，定时备份就等于没做。
