正确写法是用双引号包裹路径并转义百分号：mysqldump -u root -p database_name > "backup_$(date +\%Y\%m\%d).sql"；需转义%因mysqldump也解析%格式符，crontab中应改用反引号或指定SHELL=/bin/bash。
mysql备份命令里怎么用date生成带日期的文件名
直接在mysqldump命令中嵌入$(date)就行，但必须用双引号包裹整个输出路径，否则shell不会展开变量。单引号会把$(date)当字面量，结果就是备份文件名叫backup_$(date +\%Y\%m\%d).sql，而不是你想要的backup_20240615.sql。
常见错误现象：备份后发现文件名含$和括号、date命令没执行、或者报错command not found——基本都是引号用错了或$被转义了。
- 正确写法：
mysqldump -u root -p database_name > "backup_$(date +\%Y\%m\%d).sql" - 想加时间戳（避免同天多次备份覆盖）：
"backup_$(date +\%Y\%m\%d_\%H\%M).sql" - Windows WSL 或某些精简 shell 环境可能不认
$(...)，可改用反引号："backup_`date +\%Y\%m\%d`.sql" - 注意
%在date格式串里要转义成\%，否则mysqldump可能误解析为格式化参数
为什么date格式里的%要加反斜杠
因为mysqldump本身也支持--result-file等带%的选项，而shell在双引号内解析$(date)前，会先处理%。不转义的话，像%Y可能被提前截断或报错bad format，尤其在老版本bash或dash下更敏感。
使用场景：CI脚本、定时任务（crontab）、一键备份脚本——这些地方对命令稳定性要求高，一个未转义的%就可能导致备份失败且无提示。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 安全写法一律用
\%Y\%m\%d，别省那个反斜杠 -
date +\%F看着简洁，但%F等价于%Y-%m-%d，含横线，部分系统或工具（如某些FTP客户端）对文件名中的-敏感，不如\%Y\%m\%d稳妥 - 如果用
strftime类函数在应用层拼接，也要注意语言自身是否对%二次转义（比如Python的strftime不用加\，但shell里必须加）
crontab里执行时date不生效怎么办
crontab默认用/bin/sh，不是bash，不支持$(...)语法，也不加载你的~/.bashrc，所以date命令可能找不到，或$(date)直接报错退出，导致备份静默失败。
性能影响不大，但兼容性是硬伤：同一行命令在终端能跑，放进crontab就卡住或生成空文件。
- 最稳方案：写成独立脚本（如
/home/user/bin/backup.sh），开头加#!/bin/bash，再用$(date) - 如果坚持单行，改用
`date +\%Y\%m\%d`（反引号），/bin/sh普遍支持 - 务必在crontab里指定
SHELL=/bin/bash，并在命令前加PATH环境变量，例如：PATH=/usr/local/bin:/usr/bin:/bin - 测试方法：手动运行
env -i /bin/sh -c 'echo `date +\%Y\%m\%d`'，看是否输出日期
备份文件名里要不要包含数据库名和主机信息
要。只靠日期不够，多个库或多个实例共用一个备份目录时，backup_20240615.sql根本分不清是谁的，恢复时容易拿错文件。这不是“最佳实践”建议，是线上事故高频原因。
容易踩的坑：本地测试时只有一个库，觉得“反正就一个”，上线后加了新库，备份脚本没改，结果每天覆盖同一个文件，某次恢复才发现最近一周全是A库的数据，B库丢了。
- 推荐命名模板：
"${DB_NAME}_$(hostname)_$(date +\%Y\%m\%d_\%H\%M).sql" - 如果
DB_NAME含特殊字符（如-、.），建议用${DB_NAME//[^a-zA-Z0-9]/_}简单清洗（bash 4.0+） - 不要用
$(pwd)或$(basename $0)代替主机名——脚本可能被软链接调用，或从不同路径执行，不可靠 - 压缩一步到位：
mysqldump ... | gzip > "${DB_NAME}_$(date +\%Y\%m\%d).sql.gz"，节省空间且减少IO压力
