查询服务器级别的字符集
服务器级别的字符集是MySQL实例的默认设置，当创建新的数据库或表且未明确指定字符集时,MySQL将采用服务器级别的默认字符集。
查询方法：
最直接的方法是查询系统变量,使用以下SQL命令：
SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'collation_server';
character_set_server：此变量定义了服务器的默认字符集，常见值为latin1、utf8或更为推荐的utf8mb4。collation_server：此变量定义了服务器的默认排序规则，排序规则是在字符集基础上用于定义字符比较顺序的规则，utf8mb4_general_ci（不区分大小写）或utf8mb4_bin（按二进制值比较）。
结果解读：
如果输出显示 character_set_server 为 latin1，意味着所有新创建的数据库，如果未加指定，都将使用latin1字符集，这显然无法存储中文字符，在现代应用中，强烈建议将此值设置为 utf8mb4,以支持包括Emoji在内的所有Unicode字符。
查询数据库级别的字符集
数据库级别的字符集是该库中所有新表的默认字符集，它可以继承服务器的设置,也可以在创建数据库时被明确指定。
查询方法：
有两种常用方法来查询特定数据库的字符集。
-
使用
SHOW CREATE DATABASE命令：SHOW CREATE DATABASE your_database_name;
请将
your_database_name替换为你的实际数据库名，在返回的结果中，寻找DEFAULT CHARSET部分,它会明确指出该数据库的默认字符集。 -
查询
information_schema数据库：SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_database_name';
这种方法更适合通过脚本或程序来批量获取信息，结果以表格形式呈现,清晰明了。
结果解读：
如果发现某个数据库的字符集不是预期的（是latin1而你期望的是utf8mb4），那么这个数据库中后续创建的表如果不指定字符集，都会沿用错误的设置,从而埋下乱码隐患。
查询数据表级别的字符集
数据表级别的字符集是该表中新列的默认字符集，同样，它会继承数据库的设置,也可以在创建表时被覆盖。
查询方法：
-
使用
SHOW CREATE TABLE命令：SHOW CREATE TABLE your_table_name;
在输出的建表语句末尾，可以看到
ENGINE=InnoDB DEFAULT CHARSET=...这样的字样，这里的CHARSET就是表的默认字符集。 -
查询
information_schema数据库：SELECT TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';
注意，这里查询的是
TABLE_COLLATION（表的排序规则），排序规则的命名规则通常是字符集名_排序规则，因此通过排序规则名称就可以反推出字符集。utf8mb4_unicode_ci表明该表的字符集是utf8mb4。
结果解读：
检查表的字符集是定位乱码问题的关键步骤，有时，即使数据库字符集正确，也可能因为某张表是在错误配置时期创建的,导致其字符集不正确。
查询列级别的字符集
列级别的字符集具有最高优先级，即使在表级别设置了字符集，仍然可以为单个列（通常是 CHAR, VARCHAR, TEXT 类型）指定不同的字符集。
查询方法：
最全面的方法是查询 information_schema 数据库中的 COLUMNS 表。
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';
这个查询会列出指定表中所有列的详细信息,包括它们各自的数据类型和字符集。
结果解读：
这是最精细的查询，如果发现某张表的大部分列都是utf8mb4，唯独一个存储关键信息的列是latin1，那么数据在插入该列时就会出问题,这种情况在数据库迁移或升级时可能出现。
查询客户端连接的字符集
数据在服务器端存储正确，不代表客户端就能正确显示，客户端、服务器连接、服务器端结果的字符集必须协调一致，这个过程常被称为“字符集转换之旅”。
查询方法：
执行以下命令可以查看当前连接的所有相关字符集变量：
SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%';
关键变量解读：
| 变量名 | 描述 |
|---|---|
character_set_client |
服务器认为客户端发送查询时所使用的字符集。 |
character_set_connection |
服务器接收到查询后，将其转换成的字符集。 |
character_set_results |
服务器返回查询结果（数据、错误信息等）给客户端时所使用的字符集。 |
character_set_database |
当前默认数据库的字符集。 |
最佳实践： 为了避免不必要的转换和潜在问题，通常建议将 character_set_client、character_set_connection 和 character_set_results 设置为相同的值，最好是 utf8mb4，大多数现代数据库连接驱动和客户端（如MySQL Workbench, Navicat）都会自动尝试设置为最合适的字符集。
故障排查与总结
当遇到乱码问题时，可以按照以下顺序进行排查,形成一个完整的排查链路：
- 检查数据源： 确认你要插入的数据本身是什么编码。
- 检查连接： 执行
SHOW VARIABLES LIKE 'character_set%';，确认客户端连接的三个关键变量（client,connection,results）是否正确,这是最常见的问题所在。 - 检查目标列： 使用
SHOW FULL COLUMNS FROM your_table_name;或上述列级别的查询,检查你正在操作的列的字符集是否正确。 - 检查目标表： 检查表的默认字符集。
- 检查目标库： 检查数据库的默认字符集。
- 检查服务器： 最后检查服务器的默认字符集。
通过这一套从外到内、从应用到存储的查询体系，可以精确地定位MySQL字符集配置的任何一个环节，正确的字符集配置是数据准确性和应用国际化的基石，熟练掌握这些查询方法，将使你在处理多语言数据时游刃有余，如果需要修改已有数据库或表的字符集，可以使用 ALTER DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; 和 ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; 等命令,但执行前务必备份数据。
