刚接手一套历史遗留的库表结构时，你大概率会碰到这个问题：用一条 CREATE DATABASE 建库，到底要不要手动指定字符集？写 utf8mb4 还是老掉牙的 utf8？MySQL 8 的默认排序规则又换成了什么？这些细节没搞清楚，后面 ALTER DATABASE、DROP DATABASE 跟着全是坑。这篇内容就把 MySQL 8 里数据库生命周期管理这三条语句讲透，重点放在语法的实际变化、参数选择的依据、以及执行时容易忽略的边界情况。日常维护数据库的开发者、运维同学，以及正在把老项目从 5.7 往 8.0 迁移的团队，都可以直接拿这篇当参考。
我见过不少同学在一台新装好的 MySQL 8 上直接敲 CREATE DATABASE demo，不跟任何参数，觉得能连上就行。真上线后才发现库的默认排序规则是 utf8mb4_0900_ai_ci，应用里某些 SQL 对字符串比较逻辑又比较敏感，一堆问题呼啦一下全冒出来。其实这些问题在最开始那一条建库语句里就能规避。下面我会把三条语句从语法到实操拆开讲，再补一份报错速查表，尽量让这篇内容能直接当工作手册用。
1. 三个语句在 MySQL 8 中的整体变化
1.1 从 5.7 到 8.0：默认值才是最大的坑
MySQL 8.0 发布后，最容易被忽视的变化不在某个复杂新特性，而在默认值。老版本里 character_set_server 默认是 latin1，collation_server 默认是 latin1_swedish_ci；MySQL 8.0 直接改成 utf8mb4 和 utf8mb4_0900_ai_ci。这意味着如果你在 8.0 上不写任何参数执行 CREATE DATABASE，得到的库默认就是 utf8mb4_0900_ai_ci，而不是以前“什么都不写默认 latin1”的老规矩。
这个变化影响很大。原来跑在 5.7 上的应用，如果建表时也都没指定字符集，迁移到 8.0 后，新建表的存储字符集会自动变成 utf8mb4。表面上看是“升级了”，但 utf8mb4 和 latin1 在排序、索引长度、存储占用上都不一样。比如 varchar 字段在 utf8mb4 下，索引长度限制按字符计算，单列索引最大 3072 字节，之前 latin1 时 255 个字符没问题，换成 utf8mb4 后相同字符数可能就超出索引长度限制。这类问题隐藏得很深。
utf8mb4_0900_ai_ci 是基于 Unicode 9.0 的排序规则，对表情符号、特殊文字的支持比 5.7 时代常用的 utf8mb4_general_ci 更准确。它默认不区分大小写、不区分音调，比较规则更符合现代语言习惯。但需要特别注意，这个排序规则是 MySQL 8.0 专属，如果把 8.0 上的备份文件拿回 5.7 恢复，或者让 5.7 的从库去同步 8.0 主库的 DDL，很可能直接报 unknown collation 错误。所以迁移前务必想清楚前后端版本匹配。
1.2 语句本身的演进：IF EXISTS 与加密选项
MySQL 8 的 CREATE、ALTER、DROP DATABASE 在核心语法上延续了旧版本，但细节上做了不少增强。CREATE DATABASE 支持 IF NOT EXISTS，DROP DATABASE 支持 IF EXISTS，这在脚本化运维里非常有用。举个例子，一个初始化脚本可能要跑很多次，如果第一条 CREATE DATABASE 不写 IF NOT EXISTS，第二次执行就会报 ERROR 1007，整个脚本中断。加上 IF NOT EXISTS 后，重复执行就是“跳过 + 提示 warning”，脚本可以放心重入。
ALTER DATABASE 在 8.0.13 以后增加了 ENCRYPTION 子句，支持设置库级别的默认加密属性。8.0.16 以后又增加了 READ ONLY 子句，可以把某个库直接标记为只读。这些新能力让数据库管理语句从纯粹的“建、改、删”扩展到了安全属性管理，后面我会单独展开。
还需要提一个废弃项：ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME。这个在 5.7 时代是用来升级老版本数据目录名称的，8.0.20 里面已经标记为废弃，执行会出现 warning，后续版本直接移除。所以不要在新的变更脚本里写它。
2. CREATE DATABASE：建库实操与参数选择
2.1 语法逐项拆解
MySQL 8.0 官方语法如下：
CREATE DATABASE [IF NOT EXISTS] db_name [CHARACTER SET charset_name] [COLLATE collation_name] [ENCRYPTION [=] {'Y' | 'N'}]每个部分都有讲究。IF NOT EXISTS 解决重复执行问题，字符集和排序规则决定这个库里新建表的默认存储格式，ENCRYPTION 控制库内新建表是否默认启用表空间加密。注意，ENCRYPTION 是 8.0.13 加入的，如果你还在维护一个老版本的 MySQL，写这条子句会直接语法报错。
一个完整的建库示例：
CREATE DATABASE IF NOT EXISTS demo DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_0900_ai_ci ENCRYPTION='N';这里我加了 DEFAULT 关键字，官方语法允许写 CHARACTER SET 或 DEFAULT CHARACTER SET 两种形式，效果一样。加上 DEFAULT 更明确，告诉后面读脚本的人“这是库级默认值，不是当前会话变量”。
2.2 字符集和排序规则到底怎么选
字符集选择上，MySQL 8 里的 utf8 其实是 utf8mb3 的别名，只能存 3 字节以内的字符，像 emoji 这类 4 字节字符就存不进去。新项目一律用 utf8mb4，别再写 utf8。很多老代码里写死了 CHARACTER SET utf8，在建库和建表时无意识又踩回 utf8mb3 的坑，这是我最想劝退的一个习惯。
排序规则才是真正让人纠结的地方。拿 utf8mb4 来说，常见的有三种：
| 排序规则 | 特点 | 适用场景 |
|---|---|---|
| utf8mb4_general_ci | 老版本默认，比较规则相对简单，速度尚可，但对某些语言的排序不够精确 | 兼容老项目、对排序准确性不敏感 |
| utf8mb4_unicode_ci | 基于 Unicode 标准，比 general_ci 更准确，早期版本性能略低 | 多语言内容、需要较准确排序 |
| utf8mb4_0900_ai_ci | MySQL 8 默认，Unicode 9.0 标准，准确性与速度兼顾 | 新项目首选 |
还有 utf8mb4_bin、utf8mb4_0900_as_cs 等二进制或区分大小写的排序规则，平时用得少，但如果业务要求严格区分大小写，可以在建库时直接指定，避免后续查询强制用 BINARY 转换。
选择建议很简单：新环境直接跟默认走，CREATE DATABASE 时显式写上 utf8mb4_0900_ai_ci；如果团队里有老库需要保持一致，选 utf8mb4_general_ci 也能接受。最重要的是全套统一，不要一个库一种排序规则，否则连表查询时的关联字段比较都可能出问题。
2.3 建库后的验证手段
建库不是执行完就结束了，至少要做两步验证。第一步用 SHOW CREATE DATABASE 看库的当前定义：
SHOW CREATE DATABASE demo\G执行结果里会显示建库语句的完整定义，包括默认字符集和排序规则。第二步查系统表确认一些更细的信息：
SELECT SCHEMA_NAME, DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME, CREATE_OPTIONS, CREATED FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'demo'\GMySQL 8.0.21 以后，information_schema.SCHEMATA 里多了 CREATED 字段，能直接看到这个库的创建时间。这个字段对审计很有用，比如排查线上多出来一个库是什么时候创建的，用一条 SQL 就能定位，不用翻 binlog。
3. ALTER DATABASE：改库的适用场景与边界
3.1 语法细看与核心使用场景
ALTER DATABASE 的语法和 CREATE 很像：
ALTER DATABASE [IF EXISTS] db_name [CHARACTER SET charset_name] [COLLATE collation_name] [ENCRYPTION [=] {'Y' | 'N'}] [READ ONLY [=] {DEFAULT | 0 | 1}]主要的适用场景有三个。第一，把一个历史库的默认字符集从 latin1 或老 utf8 改成 utf8mb4；第二，调整库的默认加密属性；第三，给某个库设置只读，防止业务在非变更窗口写入。
设置只读的示例：
ALTER DATABASE demo READ ONLY = 1;执行后，在这个库里再尝试 INSERT、UPDATE、DELETE，或者创建、修改、删除表，都会被拒绝。但需要注意，DROP DATABASE 操作仍然是被允许的，这是 MySQL 官方规定的行为，删除只读库不会因为只读属性被挡住。这一点在运维流程里要记得，别以为设了只读就能百分之百防误删。
3.2 关键误区：改库不等于改表
这是 ALTER DATABASE 最容易被误解的地方。ALTER DATABASE 修改的是库级默认值，它只影响后续在这个库里新建的对象，已经存在的表不会跟着变。举例说明，某个库 demo 里已经有一张 product 表，当初建表时显式用了 latin1，或者建表时继承了当时库的默认值 latin1。现在你执行 ALTER DATABASE demo CHARACTER SET utf8mb4，product 表的实际存储字符集仍然是 latin1，不会自动变成 utf8mb4。
所以做字符集迁移时，不能只改库不查表。正确流程是先摸清存量表的字符集分布：
SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'demo';找出还停留在老字符集的表，然后逐表转换。推荐用 ALTER TABLE ... CONVERT TO CHARACTER SET 而不是 MODIFY 单列，因为前者会自动调整所有字符类型的列：
ALTER TABLE product CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;大表操作要评估锁表时间和磁盘空间，分批执行，别一股脑全跑，把业务锁死。
3.3 其他属性：加密和排序规则变更的注意点
ENCRYPTION 选项在 ALTER DATABASE 里同样可用。设置为 'Y' 需要实例已经配置好表空间加密相关的组件，比如 keyring 插件或组件，否则执行会报错。而且它同样只影响后续新创建的表，已有表需要单独处理。如果只是为了存量数据加密，直接在实例层面开启相关配置后，对现有表执行 ALTER TABLE ... ENCRYPTION='Y' 逐个转换。
排序规则变更还要注意兼容性。MySQL 8 会校验字符集和排序规则是否能配套使用，比如指定 CHARACTER SET utf8mb4 同时又指定 COLLATE latin1_swedish_ci，会直接报 ERROR 1253：COLLATION 'latin1_swedish_ci' is not valid for CHARACTER SET 'utf8mb4'。这种报错其实是在保护你，避免生成一个“半吊子”配置的库。
另外提醒一点：ALTER DATABASE 修改排序规则，对已有连接的当前默认数据库是否生效，取决于连接重新初始化或重新 USE 库。已经建立的连接里，如果客户端有缓存，可能还能看到旧配置，遇到这类问题先让连接重连即可。
4. DROP DATABASE：删库的正确姿势
4.1 语法与行为说明
DROP DATABASE 的语法很简洁：
DROP DATABASE [IF EXISTS] db_name对照官方文档，后面还可以跟 RESTRICT 或 CASCADE，但这两个关键字只是被语法解析器接受，并不会产生任何额外效果。这一点和 Oracle、PostgreSQL 完全不同，初次接触很容易误以为 MySQL 也支持级联删除限制或强制删除语义。
执行 DROP DATABASE 会删除库里的所有表、视图、存储过程、触发器以及库目录本身。如果库不存在，且语句里没有 IF EXISTS，会报 ERROR 1008；写了 IF EXISTS 则只会产生一条 warning，不会中断脚本。从 binlog 角度看，DROP DATABASE 记录的是逻辑删除操作，在从库回放时会带上 IF EXISTS 语义，所以主从复制环境下一般不会因为库已不存在而报错中断。
有一个值得注意的行为：InnoDB 在默认配置下是每张表一个独立表空间文件（innodb_file_per_table=ON），删除库里的表会删除对应的 .ibd 文件，磁盘空间能够真正释放。如果某些表还停留在共享表空间里，删除后空间不一定马上归还操作系统，需要结合表空间整理来判断。这一点在“删库后磁盘空间没少”的排查场景里很关键。
4.2 删库前的风险评估与备份先行
删库在线上永远是一次高风险变更，我建议把它当成上线发布来对待，而不是随手敲一条命令。实操上分四步。
第一步，确认环境。登录后执行 SELECT DATABASE() 先看当前所在库；再确认操作目标是测试库还是生产库。最稳妥的做法是在删除前把当前实例的 server_id、hostname 打出来，对照变更单核对。第二步，备份。单库备份用 mysqldump 可以这样：
mysqldump --single-transaction --routines --triggers --events \ --databases demo > /backup/demo_$(date +%F).sql--routines 和 --triggers 对应存储过程、函数和触发器，--events 对应事件调度器，少一个，恢复出来的库就不完整。--single-transaction 用于 InnoDB 一致性快照备份，避免备份期间阻塞业务写入。第三步，在备份落盘后，确认文件大小和头部内容没问题，再执行 DROP DATABASE。第四步，删除后立刻做一次“备份可恢复验证”，不一定要恢复全量数据，至少在临时实例上把备份导进去，确认能正常建库查数。
4.3 误删之后还有没有救
误删后的恢复完全取决于备份策略。如果刚才的 mysqldump 备份存在，恢复很简单：
mysql < /backup/demo_2025-01-01.sql如果需要恢复到删除前的某一个时间点，就要配合 binlog 做增量回放。思路是先恢复全量备份，再用 mysqlbinlog 把删除时刻之前的事务补回去：
mysqlbinlog --start-datetime="2025-01-01 10:00:00" \ --stop-datetime="2025-01-01 10:30:00" binlog.000123 | mysql这个方案有两个前提：实例开了 binlog，并且日志还保留在本地。很多团队 binlog 保留天数设得短，删除操作又发生在几天前，日志早就清了，这种情况下基本只能从全量备份恢复，丢失备份点之后的数据。所以说一千道一万，备份和恢复演练的价值永远高于任何“大招”。
预防性策略同样重要。给应用账号只授予它需要的库权限，不要把全局 DROP 权限随手分发；关键库可以设置只读；变更窗口尽量选业务低峰，并安排有经验的同事一起确认。删库这件事，慢一点、稳一点，永远不吃亏。
5. 权限、报错与排查技巧速查
5.1 权限体系速览
MySQL 8 的权限体系比 5.7 更严格，执行三条语句需要的权限分别是：CREATE DATABASE 需要全局 CREATE 权限；ALTER DATABASE 需要 ALTER 权限；DROP DATABASE 需要 DROP 权限。注意，全局权限是数据库级别之上的，不能简单用GRANT ALL ON demo.*来授予创建数据库的权限，因为目标库还不存在，授权对象无法定位。
实际运维中常用的授权方式：
CREATE USER 'app_dev'@'%' IDENTIFIED BY '运维修改密码'; GRANT CREATE ON *.* TO 'app_dev'@'%'; GRANT ALTER, DROP ON `demo`.* TO 'app_dev'@'%';第一个 GRANT 给的是全局建库权限，第二个 GRANT 把 demo 库的修改、删除权限限定在库内，避免应用账号拥有跨库操作的能力。MySQL 8 还引入了更细粒度的权限分类，如果不确定当前用户有什么权限，执行 SHOW GRANTS FOR 'app_dev'@'%' 查看。
5.2 高频报错整理
| 报错信息 | 场景 | 处理方法 |
|---|---|---|
| ERROR 1007 (HY000): Can't create database 'demo'; database exists | 重复执行 CREATE DATABASE，且未使用 IF NOT EXISTS | 脚本里加上 IF NOT EXISTS，或先查询 information_schema 判断 |
| ERROR 1008 (HY000): Can't drop database 'demo'; database doesn't exist | 删除不存在的库，且未使用 IF EXISTS | 加 IF EXISTS 避免中断 |
| ERROR 1044 (42000): Access denied for user | 没有对应权限 | 按最小权限原则补授权，或确认当前登录账号是否使用了错误主机 |
| ERROR 1253 (42000): COLLATION 'latin1_swedish_ci' is not valid for CHARACTER SET 'utf8mb4' | 字符集和排序规则不匹配 | 选择配套的排序规则，如 utf8mb4_0900_ai_ci 或 utf8mb4_general_ci |
| ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci' | 低版本实例读取高版本备份 | 备份时统一字符集，或先升级接收端实例版本 |
| ERROR 1290 (HY000): The MySQL server is running with the --read-only option | 实例只读模式下执行 DDL | 确认实例是否开启全局只读，需要变更时临时关闭 |
| Warning: 'ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME' is deprecated | 用了废弃语法 | 去掉该子句，改用正常 ALTER DATABASE |
报错不可怕，怕的是不看错误码直接凭感觉处理。上面这些错误里，1007、1008 属于幂等性问题和条件判断问题，加 IF EXISTS 基本能解决；1044 是权限模型问题；1253 和 1273 是字符集兼容问题；1290 是实例级只读问题。排查时先看错误码，再看语境，基本很快能定位。
5.3 大小写敏感是个隐藏雷区
最后说一个很多团队直到上线才发现的坑：数据库名大小写敏感度。MySQL 的 lower_case_table_names 参数决定了库名和表名是否区分大小写，Linux 上默认值为 0，区分大小写；Windows 上默认值为 1，不区分大小写。也就是说，在 Linux 环境里，CREATE DATABASE Demo 和 CREATE DATABASE demo 会得到两个不同的库；在 Windows 环境里，它们会被当成同一个库处理。
MySQL 8.0 对这个参数的管理更严格，它只能在实例初始化时指定，初始化完成后不能动态修改。如果初始化时设成 0，后续想改成 1，数据库会拒绝启动，或者需要重新初始化实例。这要求你在建实例阶段就定好命名规范。
我的建议是，所有环境统一使用小写库名，代码里也全小写引用。这样在 Linux、Windows、容器环境之间切换都不会踩大小写不一致的问题，避免出现“本地开发正常，上线 Linux 找不到表”的尴尬。数据库对象命名这类基础规范，看起来不起眼，却能在关键时刻省下大把排查时间。
6. 实操中的几个操作习惯
6.1 建库三件套：IF NOT EXISTS、字符集、排序规则
我现在写任何建库脚本，默认都会写齐这三件套，一个都不省。IF NOT EXISTS 保脚本幂等，字符集和排序规则显式指定，避免依赖服务器默认值。即使环境初始化时已经统一设好了全局变量，脚本里再写一遍也没有坏处，反而让后来接手的人一眼看清设计意图。默认值会变，脚本里的显式声明不会。
6.2 改库之前先看库的当前定义
不管是改字符集还是改只读属性，执行 ALTER DATABASE 之前，先跑一遍 SHOW CREATE DATABASE，确认当前库的真实状态。我遇到过不少回滚麻烦的案例，就是没看原始定义直接改，改完发现还要还原，只能靠记忆去拼原来的字符集和排序规则组合。先查后改，成本几乎为零，收益很明显。
另外，所有库结构变更，包括 CREATE、ALTER、DROP DATABASE，都应该记录在案。MySQL 8 的 binlog 和数据字典会留下痕迹，但那是机器日志，团队内部还是要有自己的变更记录，里面写清楚变更人、变更时间、目的、影响范围。长期维护的库，这点习惯能救命。
6.3 删库之后的恢复演练比删库本身更重要
我自己的流程是：备份完成之后一定先尝试恢复一遍，再删正式库。哪怕是测试环境，也要养成“备份可恢复”才有资格删数据的习惯。删库用了 0.1 秒，恢复可能用十分钟，但如果十分钟能把一切复原，那这 0.1 秒的错就还有挽回余地。
如果团队有条件，可以定期做一次完整的“备份 + binlog 恢复到任意时间点”演练，不一定要恢复全库，挑一个核心库做演练就行。真遇到线上误删，大脑是慌张的，手是抖的，唯一靠得住的就是平时演练过无数遍的恢复流程。这不是什么高深技术，就是熟练度。
我自己实际踩过一个大坑，当时就是以为 ALTER DATABASE 改了字符集，表就会跟着变，结果线上导数据全是乱码，查了半天才发现是存量表的表级字符集没动。那次之后，我把检查 information_schema.TABLES 写进了处理流程的固定步骤，后面就再没翻过车。搞数据库管理，永远不要嫌检查步骤多，多一次确认，少一次事故。
