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

my.ini

[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%';

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

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

utf8

utf8

utf8

utf8mb4

utf8mb4

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

我的建议是：无脑选

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

以上就是MySQL如何设置字符集和排序规则 中文存储的基础配置的详细内容，更多请关注php中文网其它相关文章！