MySQL如何将utf8升级为utf8mb4配置教程

有一个很容易忽略的问题：既要修改配置文件，也要执行 ALTER TABLE CONVERT TO CHARACTER SET，这两个步骤都不能少。因为单独执行 ALTER DATABASE，只会修改数据库的默认字符集，并不会同步更新已经存在的表和字段字符集定义。这样一来，这些字段仍会按照 utf8（utf8mb3）解析 4 字节 Emoji，出现报错就很常见了。

正确做法是同时修改配置文件，并批量执行 ALTER DATABASE 与 ALTER TABLE ... CONVERT TO CHARACTER SET。如果只改服务端配置，或者只修改表结构，插入 Emoji 时仍然可能报 Incorrect string value 错误。

为什么不能只执行 ALTER DATABASE？

ALTER DATABASE 仅修改数据库的默认字符集，不会影响现有表和字段的实际定义。如果表结构中仍然保留 utf8（即 utf8mb3）声明，MySQL 在读写时依旧按 3 字节字符集处理，遇到 4 字节 Emoji 时就会截断或直接报错。

• 可通过 SHOW CREATE TABLE table_name 查看建表语句，如果字段定义中仍然存在 CHARACTER SET utf8，说明转换还未生效。
• 即使 character_set_database 已经是 utf8mb4，只要表字段显式声明为 utf8，仍会优先使用字段级设置。
• 如果索引字段是 VARCHAR(255)，且没有开启 innodb_large_prefix，直接执行 CONVERT 可能失败，此时需要先调整 innodb_file_format。

my.cnf 必须同时配置三段，否则连接层仍可能是 utf8

MySQL 的连接字符集由客户端、命令行工具和服务端三部分共同决定。即使只在 [mysqld] 段设置了 character-set-server = utf8mb4，使用 mysql 命令行连接后，character_set_client 仍然可能是 utf8。

• [mysqld]：添加 character-set-server = utf8mb4 和 collation-server = utf8mb4_0900_ai_ci，这是 MySQL 8.0 常用配置，不使用 utf8mb4_unicode_ci。
• [client]：添加 default-character-set = utf8mb4，该设置会影响 mysqldump、mysqladmin 等客户端工具。
• [mysql]：添加 default-character-set = utf8mb4，该配置仅作用于 mysql 命令行客户端。
• 如果使用 Docker，需将 my.cnf 挂载到 /etc/mysql/my.cnf，并将权限设置为 644，否则 MySQL 可能会直接跳过加载该配置文件。

如何批量将所有表转换为 utf8mb4？

逐条手动编写 ALTER TABLE 语句并不现实。通常可以通过 information_schema 生成批量转换语句，同时要保证排序规则保持一致。

• 先查询当前数据库下所有表的转换语句：

  SELECT CONCAT('ALTER TABLE `', TABLE_SCHEMA, '`.`', TABLE_NAME, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;') AS stmt FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db_name';

• 复制查询结果后，在 MySQL 客户端中批量执行，不建议使用 phpMyAdmin 的“多查询”模式，以免执行过程中中断。
• 如果某些表包含全文索引，或前缀索引长度超限，执行失败时可先执行：SET SESSION innodb_file_per_table = ON; SET SESSION innodb_file_format = Barracuda;
• 执行完成后，再通过 SHOW CREATE TABLE your_table 检查字段定义，确认已全部转换为 utf8mb4。

另一个经常被忽略的环节是应用连接参数。即使数据库端已经全部配置完成，PHP 的 mysqli 或 PDO 也仍需显式指定 charset=utf8mb4，否则连接初始化时依然可能使用默认的 utf8。这一点在宝塔和 Docker 环境中尤其容易遗漏。