MySQL如何设置字符集和排序规则 中文存储的基础配置

确保mysql正确存储中文需统一使用utf8mb4字符集和utf8mb4_unicode_ci排序规则；2. 修改服务器配置文件my.cnf或my.ini，设置character-set-server和collation-server为utf8mb4和utf8mb4_unicode_ci，并重启服务；3. 创建数据库时指定character set utf8mb4 collate utf8mb4_unicode_ci，或用alter database修改默认字符集（不影响已有表）；4. 创建表时明确指定字符集，或对已存在表执行alter table … convert to character set utf8mb4 collate utf8mb4_unicode_ci以转换数据编码（操作前必须备份）；5. 客户端连接时需通过连接参数如useunicode=true&characterencoding=utf8mb4或执行set names utf8mb4确保通信编码一致；6. 中文乱码主因包括服务器默认latin1、建库建表未指定utf8mb4、客户端连接编码不匹配、数据导入导出编码不一致及混淆utf8与utf8mb4；7. utf8mb4支持4字节utf-8编码，可存储表情符号和生僻字，而mysql的utf8仅支持3字节，存在兼容性缺陷；8. 推荐无条件使用utf8mb4以确保全面字符支持、避免未来迁移成本且性能影响可忽略；9. 检查字符集用show variables、show create database/table及查询information_schema.columns；10. 修改现有结构前必须完整备份，优先使用alter table convert to处理数据转换，若数据已乱码需按原始编码导出、转码后再导入以修复。

在MySQL中正确存储中文，核心在于确保数据库、表以及客户端连接都统一使用

utf8mb4

字符集和

utf8mb4_unicode_ci

（或

utf8mb4_general_ci

）排序规则。这样能有效避免中文乱码问题，确保数据完整性。

解决方案

要彻底搞定MySQL的中文存储，需要从几个层面进行配置，这就像是给数据流的每一个环节都贴上正确的“语言标签”。

首先，从服务器层面入手，这是最根本的。修改MySQL的配置文件

my.cnf

（linux）或

my.ini

（windows），在

[mysqld]

段落下加入或修改以下两行：

[mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci

改完记得重启MySQL服务。这样做的好处是，以后新建的数据库和表，如果没有特别指定，都会默认继承这个设置，省去不少麻烦。我个人觉得，这一步是“一劳永逸”的基础。

接着，是数据库层面的设置。如果你要新建一个数据库来存放中文数据，最好在创建时就明确指定：

CREATE DATABASE your_database_name     CHARACTER SET utf8mb4     COLLATE utf8mb4_unicode_ci;

如果数据库已经存在，但字符集不对，可以通过

ALTER DATABASE

来修改：

ALTER DATABASE your_database_name     CHARACTER SET utf8mb4     COLLATE utf8mb4_unicode_ci;

不过要注意，

ALTER DATABASE

只改变数据库的默认字符集，对已存在的表和数据是没影响的。它只作用于未来新建的表。

然后是表层面。创建表时同样要指定：

CREATE TABLE your_table_name (     id INT AUTO_INCREMENT PRIMARY KEY,     content VARCHAR(255) ) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

对于已经存在的表，并且需要转换其内部数据编码的，可以使用

ALTER TABLE ... CONVERT TO

：

ALTER TABLE your_table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

这条命令会把表中的所有

CHAR

、

VARCHAR

、

TEXT

类型的列都转换为

utf8mb4

，并且会重建表，所以操作前务必备份数据。这是个比较“重”的操作，但很多时候也是不得不为之的。

最后，也是最容易被忽视的一环——客户端连接。应用程序在连接MySQL时，也要告诉MySQL它发送和接收的数据是什么编码。这通常通过连接字符串参数或者执行

SET NAMES

命令来完成。

例如，在Java中，连接URL可能看起来像这样：

jdbc:mysql://localhost:3306/your_database_name?useUnicode=true&characterEncoding=utf8mb4

或者，在每次连接成功后执行：

SET NAMES utf8mb4;

我发现很多中文乱码问题，最终都归结到这一步没设置对。服务器、数据库、表都对了，但客户端连接“说”的是另一种语言，那数据过来过去就全乱了。

为什么我的MySQL中文会出现乱码？常见字符集问题解析

中文乱码，这简直是中文开发者挥之不去的噩梦。它通常不是单一原因造成的，而是多环节编码不一致的“连锁反应”。简单来说，就是数据在从你的键盘输入，经过应用程序，到MySQL存储，再到被读取显示出来的整个过程中，某个环节对字符编码的理解出了偏差。

最常见的原因，我觉得有这么几个：

1. 服务器默认字符集不匹配： MySQL服务器在安装时，如果没特别配置，默认可能是

   latin1

   。当你在这个环境下创建数据库或表，它们很可能继承了

   latin1

   ，但你的中文数据是UTF-8编码的，一存进去就成了乱码。就好比你用中文写了一封信，却用英文字典的规则去编码，对方收到自然是天书。

2. 数据库或表创建时未指定UTF-8： 即使服务器默认是

   utf8mb4

   ，如果你在创建数据库或表时，手滑没写

   CHARACTER SET utf8mb4

   ，或者用了旧的脚本，它可能还是用了其他编码。

3. 应用程序连接编码问题： 这是一个大头。你的代码可能发送的是UTF-8编码的中文，但MySQL以为你发送的是

   latin1

   或者其他编码。反之亦然，MySQL返回的是UTF-8，但你的程序用

   GBK

   去解析，一样乱。

   SET NAMES utf8mb4

   就是为了解决这个问题，它告诉MySQL：“我跟你说的、我听你说的，都是

   utf8mb4

   ！”。

4. 数据导入导出时编码不一致： 比如你从一个

   GBK

   编码的文本文件导入数据到

   utf8mb4

   的MySQL表里，或者反过来，都可能导致乱码。

   mysqldump

   在导出时，也需要注意

   --default-character-set

   参数。

5. utf8

   和

   utf8mb4

   的混淆： 这一点下个问题会详细说，但简而言之，MySQL的

   utf8

   并不是完整的UTF-8，它可能无法存储某些特殊字符（比如表情符号），一旦存入，就会报错或者显示为问号。

诊断乱码问题时，我通常会先用

SHOW VARIABLES LIKE 'character_set%';

和

SHOW VARIABLES LIKE 'collation%';

来检查当前MySQL会话、数据库和表的实际编码设置。这能帮你快速定位是哪个环节出了问题。

utf8mb4和utf8有什么区别？选择哪一个更适合中文存储？

说起这个，就不得不提MySQL的“历史遗留问题”了。很多人都觉得

utf8

就是UTF-8，但实际上，在MySQL里，它们不是一回事。

utf8

(MySQL特有)： 这是MySQL早期实现的一种UTF-8编码，它最多支持每个字符3个字节。对于大多数常见的汉字（属于Unicode基本多文种平面BMP），3个字节是够用的。所以，如果你只存储普通的中文汉字，

utf8

在理论上是够用的。

utf8mb4

(真正的UTF-8)：

utf8mb4

才是完全符合Unicode标准、支持每个字符最多4个字节的UTF-8编码。这意味着它能存储包括所有汉字在内的所有Unicode字符，尤其是那些在基本多文种平面之外的字符，比如表情符号（emojis）、一些生僻字、特定语言符号等。

选择哪一个更适合中文存储？

我的建议是：无脑选

utf8mb4

。

为什么这么说？

1. 更全面的字符支持： 随着互联网内容的多样化，用户输入中出现表情符号、特殊符号的情况越来越多。如果你用了

   utf8

   ，当用户输入一个表情符号时，你的数据库可能就会报错，或者直接把这个字符变成问号或乱码。

   utf8mb4

   则能完美支持这些。

2. 避免未来兼容性问题： 即使你现在不存储表情符号，谁能保证未来不需要呢？一旦业务发展，需要存储这些字符，再从

   utf8

   转到

   utf8mb4

   会是一个比较麻烦的过程，涉及到表重建和数据迁移。不如一开始就用最全面的方案。

3. 性能影响微乎其微： 很多人担心

   utf8mb4

   会占用更多存储空间或影响性能。确实，理论上4字节的编码会比3字节多占空间，但对于现代存储设备和数据库系统来说，这种差异在绝大多数应用场景下都是可以忽略不计的。索引长度可能会有轻微影响，但通常也不是瓶颈所在。

所以，为了避免未来的“坑”，为了更健壮、更现代化的应用，直接使用

utf8mb4

是最佳实践。这就像买房子，能一步到位就不要想着以后再加盖。

如何检查和修改现有MySQL数据库的字符集与排序规则？

检查和修改现有数据库的字符集和排序规则，是处理历史遗留问题或排查乱码的关键步骤。这就像给你的房子做一次全面的体检和翻新。

1. 检查当前设置：

• 服务器级别：

  SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%';

  这里你会看到

  character_set_server

  和

  collation_server

  ，它们是MySQL实例的默认设置。还有

  character_set_database

  、

  character_set_client

  、

  character_set_connection

  等，分别代表数据库、客户端发送和连接的字符集。

• 数据库级别：

  SHOW CREATE DATABASE your_database_name;

  这条命令会显示创建数据库时的sql语句，其中包含了它的

  CHARACTER SET

  和

  COLLATE

  。

• 表级别：

  SHOW CREATE TABLE your_table_name;

  类似地，这里会显示创建表的SQL语句，包含表的

  CHARACTER SET

  和

  COLLATE

  。

• 列级别：

  SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_database_name' AND DATA_TYPE IN ('char', 'varchar', 'text', 'tinytext', 'mediumtext', 'longtext');

  这条查询能帮你找出数据库中所有文本类型列的具体字符集和排序规则，非常详细。

2. 修改现有设置（慎重操作，务必备份！）：

修改现有数据库或表的字符集，特别是当涉及到数据转换时，是一个高风险操作。我强调一下，在进行任何修改之前，请务必对你的数据库进行完整备份！

• 修改数据库默认字符集：

  ALTER DATABASE your_database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

  再次提醒，这只影响未来新建的表，对现有表无影响。

• 修改表字符集并转换数据： 这是最常用的，也是最关键的步骤。

  ALTER TABLE your_table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

  这条命令会读取表中的所有数据，然后按照新的字符集重新编码并写入。如果原始数据已经是乱码（比如

  latin1

  存了中文），那么直接执行这条命令可能会让乱码变得更“彻底”，因为它会尝试把错误的编码再转一次。在这种情况下，正确的做法是：

  1. 先将表的字符集设置为错误的原始字符集（例如

     latin1

     ），但不要转换数据。

  2. 然后将数据导出（使用

     mysqldump --default-character-set=latin1

     等）。

  3. 编辑导出的SQL文件，将文件编码转换为

     utf8mb4

     。

  4. 清空原表或删除重建。
  5. 最后再导入数据。 这个过程比较复杂，但对于已经损坏的数据，往往是唯一的救命稻草。

• 修改特定列的字符集： 如果你只需要修改表中某个特定列的字符集：

  ALTER TABLE your_table_name MODIFY COLUMN column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

  这条命令同样会触发列数据的转换。

整个过程，我觉得最大的挑战在于，你得清楚你的数据在“乱码”之前到底是什么编码，以及它在数据库里被“误解”成了什么编码。只有搞清楚这个，才能对症下药。否则，盲目地

ALTER

可能只会让事情更糟。