用 mysqldump + cron 实现定时备份需确保绝对路径调用、环境变量设置（LANG=C.UTF-8）、exit code 和文件完整性校验（大小、头部标识），配合 ssmtp/mailutils 发送含时间戳、数据库名、文件大小及退出码的报告，并规范 crontab 时间表达式与日志记录。
用 mysqldump + cron 实现备份并生成报告
MySQL 本身不提供定时备份和邮件通知功能，得靠系统级工具组合实现。核心是把 mysqldump 的执行结果捕获成文本报告，再通过系统命令发邮件。
常见错误是直接在 cron 里写长命令却没处理环境变量或路径——mysqldump 找不到、mail 命令不可用、中文乱码，全在这儿卡住。
- 务必用绝对路径调用
mysqldump（如/usr/bin/mysqldump），cron 默认 PATH 很窄 - 脚本开头加
#!/bin/bash并设置LANG=C.UTF-8，避免备份文件名或日志含中文时出错 - 用
set -e让脚本遇到任意命令失败就退出，别让“备份失败但邮件照发”这种事发生 - 报告内容至少包含：时间戳、数据库名、备份文件大小（
du -h）、mysqldump退出码
用 mailutils 或 ssmtp 配系统级邮件发送
Linux 发邮件不能只靠 mail 命令——它只是个接口，背后得有 MTA（邮件传输代理）支撑。多数云服务器默认没装，直接运行 echo "test" | mail -s "test" a@b.com 会静默失败。
推荐轻量方案：ssmtp（配置简单）或 mailutils（带完整 mail 命令）。别碰 postfix 或 sendmail，太重，配置稍错就卡死。
-
ssmtp配置关键三行：root=your@gmail.com、mailhub=smtp.gmail.com:587、AuthUser=your@gmail.com（注意 Gmail 要开 App Password） - 测试是否通：运行
echo "body" | mail -s "test" your@email.com，别信返回值，去收件箱看 - 如果用腾讯企业邮箱或阿里云邮件推送，替换
mailhub和认证方式即可，端口通常是 465 或 587 - 别在脚本里硬编码密码，用
ssmtp的AuthPass指向一个 600 权限的密钥文件
备份报告里必须检查 exit code 和文件完整性
很多人只看邮件有没有收到，不看内容是否真成功。一次 mysqldump 因锁表超时失败，输出空文件，但脚本仍发了“备份完成”的邮件——这比不发还危险。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
真正有用的报告，得靠命令执行后的 $? 和文件状态说话。
- 执行完
mysqldump立即检查if [ $? -ne 0 ]; then echo "dump failed" >&2; exit 1; fi - 用
stat -c "%s" backup.sql检查文件大小，小于 1KB 基本可判定异常（除非库真空） - 加一句
head -n 10 backup.sql | grep -q "MySQL dump" || { echo "not a valid dump"; exit 1; }，防文件被截断或写入权限不足导致空内容 - 报告正文里明确写出 “Exit code:
$?”，比任何文字描述都可靠
避免 crontab 时间表达式踩坑
cron 的时间语法和日常理解有偏差，最常翻车的是“每月 1 号凌晨 2 点”写成 0 2 1 * * ——看似对，但某些旧版 cron（比如 CentOS 6）会把 * 当“每项都匹配”，导致每天执行。
更稳妥的做法是显式排除干扰项，尤其涉及日期和星期同时存在时。
- 只按日期执行（忽略星期）：用
0 2 1 * *，但确认系统 cron 支持（systemd-based 发行版一般 OK） - 想避开周末？别用
0 2 1 * 1-5，而应写两行：0 2 1 * 1-5和0 2 1 * 6,0分开控制 - 所有 cron 任务加
PATH=/usr/local/bin:/usr/bin:/bin前缀，否则mysqldump或mail找不到 - 调试阶段加
>> /var/log/backup.log 2>&1，别依赖邮件——邮件可能发不出，日志才是真相
定时备份不是设完 cron 就一劳永逸的事。最容易被忽略的是磁盘空间清理和备份文件加密——没人检查 /backup/ 目录，三个月后填满根分区，连 mysqldump 都写不进临时文件。
