MySQL 数据库创建怎么做？从字符集设置到权限分配建立第一套数据库

创建MySQL数据库看起来只是执行一条CREATE DATABASE，但真正用于SaaS、网站或业务系统时，还需要同时考虑字符集、排序规则、账户权限、连接方式、存储引擎以及后续备份和性能配置。数据库一开始创建得是否合理，往往会影响后面的表结构、查询行为和维护成本。

以MySQL 8.x为例，首先应该确认服务器版本、连接方式以及管理员账户。生产环境不建议让网站程序长期使用root账户，而应该创建专门的应用账户，只授予业务真正需要的权限。

创建数据库可以使用：

CREATE DATABASE mydb
CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;

MySQL 8.4默认字符集已经是utf8mb4，默认排序规则是utf8mb4_0900_ai_ci，但在项目中显式指定仍然有意义，可以避免服务器默认配置变化造成不同环境之间的差异。MySQL官方也建议在可能的情况下使用utf8mb4，因为它能够覆盖完整Unicode字符范围。

这里需要区分字符集和排序规则。utf8mb4决定字符串如何编码和存储，而collation决定字符串比较和排序的规则。例如utf8mb4_0900_ai_ci中的ci表示大小写不敏感，ai表示重音不敏感。如果业务需要区分大小写，可以考虑utf8mb4_0900_as_cs等排序规则，而不是简单地把“unicode_ci”和“0900_ci”理解成两个不同级别的Unicode字符集。

如果项目需要用户名、账号、编码或者某些业务标识严格区分大小写，就应该在相应列上选择合适的case-sensitive或binary collation。排序规则不是越“新”越好，而应该根据实际字符串比较规则选择。MySQL官方也建议用实际业务数据测试排序和比较结果。

数据库创建完成以后，可以使用：

SHOW CREATE DATABASE mydb;

检查数据库实际使用的字符集和排序规则。MySQL 8.4的SHOW CREATE DATABASE会直接显示CREATE DATABASE语句以及默认字符集、排序规则等信息。

接下来创建应用账户：

CREATE USER 'app_user'@'localhost'
IDENTIFIED BY 'StrongPasswordHere';

GRANT SELECT, INSERT, UPDATE, DELETE
ON mydb.* TO 'app_user'@'localhost';

如果应用程序和MySQL运行在同一台服务器上，localhost通常比%更合适。'app_user'@'%'意味着允许来自任意主机的连接，这在需要远程连接时才有意义，而且还应该结合防火墙、网络访问控制以及TLS等措施进行限制。

CREATE USER创建出来的账户默认没有数据库权限，需要通过GRANT授予具体权限。MySQL官方的账户模型也是把账户创建和权限授予分开处理。

例如，一个只负责网站读写数据的账户，没有必要拥有ALTER、DROP、CREATE USER或者服务器级管理权限。权限越接近实际业务需求，数据库账户泄露以后可能造成的影响通常越小。

另外，一个常见的旧教程错误是执行GRANT以后还要求：

FLUSH PRIVILEGES;

对于正常使用CREATE USER、GRANT和REVOKE进行账户管理的情况，并不需要额外执行FLUSH PRIVILEGES，这些权限变化会立即生效。FLUSH PRIVILEGES主要用于直接修改MySQL权限表等特殊情况。

权限可以通过下面的命令检查：

SHOW GRANTS FOR 'app_user'@'localhost';

如果应用需要远程连接，还要检查MySQL服务器监听地址、防火墙和网络访问规则。bind-address决定服务器在哪个网络接口上接受连接，但单纯修改bind-address并不等于完成安全的远程数据库配置。生产环境更应该让数据库尽可能只暴露给真正需要连接的应用服务器。

连接字符集也不能忽略。数据库使用utf8mb4，并不意味着客户端连接一定已经正确使用utf8mb4。应用程序仍然需要正确配置连接字符集，让客户端和服务器之间使用一致的编码。MySQL官方也明确区分了数据存储字符集和客户端通信字符集。

存储引擎方面，现代MySQL项目通常应该优先使用InnoDB。MySQL 8.4默认存储引擎就是InnoDB，它提供事务、崩溃恢复、行级锁以及一致性读取等能力。对于普通网站、SaaS和业务系统，没有必要因为“只读”就主动把表设计成MyISAM。

数据库创建完成后，再开始设计表结构。例如用户表、订单表、文章表等，都应该明确主键、外键关系、字段类型、NULL规则以及索引。不要在数据库刚创建完成时就堆大量“预防性索引”，索引应该根据真实查询模式和业务访问路径逐步设计。

性能参数也不应该在建库阶段机械地套用固定数值。例如innodb_buffer_pool_size需要根据服务器内存和实际工作负载调整；不能简单规定所有服务器都使用某个固定比例。

原文中的innodb_log_file_size=4G也不适合作为通用配置建议。在MySQL 8.4中，innodb_redo_log_capacity已经取代innodb_log_file_size和innodb_log_files_in_group作为主要的Redo Log容量配置方式，后两者已经被标记为deprecated。Redo Log容量应该结合写入量、磁盘能力和恢复时间要求进行测试，而不是看到高并发就直接设置成4GB。

max_allowed_packet同样不能为了“避免大字段写入失败”就直接设置成1GB。MySQL 8.4服务器默认值为64MB，协议允许的最大值是1GB。只有确实存在大型BLOB、长字符串或者大批量SQL传输需求时，才应该根据实际数据大小调整，而且客户端和服务器两端的限制都需要考虑。

二进制日志则应该根据业务需要配置。MySQL 8.4默认启用binary logging并采用ROW格式，因此没有必要再把“启用log_bin和binlog_format=ROW”当成所有8.4服务器都必须手工设置的初始步骤。Binary Log真正重要的价值包括复制、恢复以及相关的数据变更追踪能力，但它本身不能简单等同于完整的数据库审计系统。

真正的数据库安全，还包括备份、账号隔离、网络访问控制、TLS、日志管理、操作系统权限以及恢复测试。特别是备份，不能因为执行了一次mysqldump就认为数据库已经安全。更重要的是确认备份文件确实能够恢复，并根据业务要求设置合理的备份频率和保留周期。

因此，创建MySQL数据库真正值得建立的流程并不是“执行CREATE DATABASE就结束”，而是从字符集和排序规则开始，建立独立的应用账户，再按照最小权限原则授予访问权限，确认连接字符集和网络访问方式，使用InnoDB建立业务表，最后建立备份、日志和恢复机制。

一个数据库最初可能只有几个表、几个用户和很少的数据，但随着网站和SaaS业务增长，真正困难的往往不是“数据库能不能创建”，而是当数据达到千万级以后，原来的索引、事务、权限、备份和查询方式还能不能继续承受业务增长。因此，第一套数据库的正确设计，实际上也是以后整个数据架构演进的起点。