在数据库迁移与备份过程中，一个几乎每周都会在技术群里被问起的问题是：使用 mysqldump 导出的 SQL 文件，为什么里面没有 CREATE DATABASE 语句？明明目标数据库就在那里，数据也没有丢失，但一旦回迁到新环境就令人措手不及——数据库必须手动重建。其实，这个现象的根源非常简单：默认情况下，mysqldump db_name 执行的仅仅是“表级导出”操作，它只负责处理表结构、数据、索引等内容，并不会自动帮你把数据库定义也包含进来。
想让 CREATE DATABASE 出现，必须使用 --databases 参数
如果你希望导出的 SQL 文件中包含 CREATE DATABASE `xxx` 和 USE `xxx` 这两行指令，那么就需要显式告诉 mysqldump：“这次是数据库级别的导出，而不是仅仅导出几张表”。关键参数就是 --databases（双短横，注意不是单短横的 --database）。
几个常见场景的区别：
- 导出单个库并同时生成建库语句：直接执行
mysqldump --databases mydb > dump.sql。这里的--databases是标准写法，语义清晰，不易产生误解。当然，你也可以使用简写形式-B mydb，但团队中可能有人看不懂这种简写。 - 导出多个库：
mysqldump --databases db1 db2 > dump.sql，每个库都会分别生成对应的CREATE DATABASE和USE语句，互不干扰。 - 误用
--database（单短横）的陷阱：这个参数只接受一个参数，行为也有所不同，本质上与--databases是同一回事，但它不会检查参数个数。如果你写成--database db1 db2，它会悄悄忽略db2，不会报错——这种静默漏库的现象在生产环境中可能是灾难。 - 贴心设计：如果目标数据库名称中包含中划线等特殊字符，
--databases会自动用反引号包裹库名，省去了手动转义的麻烦。相比之下，在脚本里硬拼CREATE DATABASE语句时，转义问题常常成为 bug 的根源。
别忘了权限这道门槛：SHOW DATABASES 是必须的
当你使用 mysqldump --databases 进行导出时，它并非简单看一眼就完事。它需要查询 INFORMATION_SCHEMA.SCHEMATA 表，获取每个库的字符集、排序规则等元数据信息，只有这样，才能生成带有 CHARACTER SET 和 COLLATE 的完整 CREATE DATABASE 语句。如果连库的字符集都无法获取，建库语句自然无从谈起。
常见的报错信息如下：Access denied; you need (at least one of) the SUPER, SHOW DATABASES privilege(s) for this operation。看到这条消息，第一反应就应该是检查数据库账号的权限。
要点：
- 连接数据库所使用的账号，必须额外授予
SHOW DATABASES权限——GRANT SHOW DATABASES ON *.* TO 'user'@'host'。注意权限范围是ON *.*，因为这条权限是针对整个实例级别的。 - 不要试图用
SELECT权限走捷径：即使你对目标库中所有表拥有SELECT权限，但缺少SHOW DATABASES，仍然无法完成导出。 - 云数据库用户尤其要注意：阿里云 RDS、腾讯云 CDB 等平台默认通常关闭了
SHOW DATABASES权限，需要自行进入控制台开启，或者提交工单联系客服解决。
与 CREATE DATABASE 相关的几个重要参数
你是不是以为只要用了 --databases 就万事大吉了？别急，还有几个坑需要注意。其他一些参数可能会干扰最终的输出结果：
--no-create-db：这个参数的作用是“强行禁用建库语句”。无论你怎么使用--databases，它都会把所有的CREATE DATABASE语句全部移除——它的优先级最高。因此，千万不要同时使用--no-create-db和--databases，这绝不是你想要的结果。--create-options：这个参数与直觉可能不同，它只影响CREATE TABLE语句中的额外属性（例如AUTO_INCREMENT、ENGINE），与CREATE DATABASE无关。不要误以为它能控制建库语句。- 导出后如何快速验证？使用
head -n 5 dump.sql查看前几行，是否有CREATE DATABASE一目了然；或者更严谨地，执行grep "^CREATE DATABASE" dump.sql | wc -l直接统计语句行数。
导入时的隐患：CREATE DATABASE 也可能导致问题
导出的文件里包含了 CREATE DATABASE，并不代表你能顺利还原成功。MySQL 的默认行为是：如果目标数据库已经存在，它会直接报错 ERROR 1007 (HY000): Can't create database 'xxx'; database exists，并卡在该处。另外，如果还原所用的账号没有 CREATE 权限，同样无法执行。
建议的做法：
- 在还原之前，可以手动在 SQL 文件开头添加
DROP DATABASE IF EXISTS `xxx`;——这样更可控，比依赖mysql命令的自动处理更加可靠。 - 使用
mysql -u user -p < dump.sql还原时，确保该用户拥有对目标实例的CREATE权限：GRANT CREATE ON *.* TO 'user'@'host'。 - 生产环境务必谨慎：不要完全依赖自动生成的
CREATE DATABASE语句。它使用的字符集、排序规则可能与目标环境的要求不一致，建议导出后人工检查再执行，或者手动构建建库语句。
最后补充一句最容易被忽视的经验：本地开发调试时使用 --databases 顺手又方便，但一旦涉及上线部署脚本，如果硬编码了库名、跳过了权限检查或忽略了字符集问题，那就等着线上出问题吧。将权限、字符集、库是否存在这三项全部列入 checklist，才是稳妥的做法。
