导出数据库时包含创建数据库语句的选项设置

在数据库迁移与备份过程中，一个几乎每周都会在技术群里被问起的问题是：使用 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，才是稳妥的做法。