MySQL中的字符集，简单说就是一套“字符→二进制编码”的映射规则。它决定了数据库如何把文字（比如“张三”“Hello”“?”）存成字节，也决定了能存哪些字符。
字符集是存储文本的“编码字典”
计算机只认0和1，所有文字必须转成字节才能保存。字符集就定义了这个转换方式：
同一个汉字“中”，在GBK里是0xD6D0（2字节），在UTF8MB4里是
0xE4B8AD（3字节） 英文“A”在ASCII、Latin1、UTF8MB4里都是
0x41（1字节），所以UTF8兼容ASCII emoji“?”需要4字节，在老版
utf8（实际是utf8mb3）中不支持，必须用
utf8mb4
字符集不是孤立存在的——它绑定校对规则（Collation）
字符集管“怎么存”，校对规则管“怎么比、怎么排”。没有校对规则，就无法做
WHERE name = 'Alice'或
ORDER BY title。
utf8mb4_general_ci：不区分大小写（
A == a），排序快，适合通用场景
utf8mb4_bin：按字节逐位比较（
A ≠ a），适合密码、token等严格匹配
utf8mb4_unicode_ci：遵循Unicode标准排序，对德语变音、法语重音等处理更准确
字符集有层级，默认会逐级继承
MySQL允许在四个级别设置字符集和校对规则：服务器 → 数据库 → 表 → 列。下级不显式指定时，自动继承上级默认值。
查看当前服务器默认：SHOW VARIABLES LIKE 'character_set_server';建库时指定：
CREATE DATABASE db1 CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;建表时指定列：
name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin
乱码往往不是字符集错，而是“链路不一致”
从客户端输入，到连接、服务端存储、再到查询返回，每个环节的字符集都要对齐。常见断点包括：
客户端连接没声明编码（如没执行SET NAMES utf8mb4） 应用程序连接字符串漏配
characterEncoding=utf8mb4表结构是utf8mb4，但字段实际用了latin1建的旧数据 导出SQL文件时未指定
--default-character-set=utf8mb4
