MySQL编码那些坑和折腾，实操中才懂的那些事儿

行，那咱们就直接开唠，MySQL用久了，谁还没踩过几个刻骨铭心的坑？有些事儿，文档上写得明明白白，但你不亲手折腾一回，永远不知道那水有多深,我跟你念叨念叨那些年让我熬夜掉头发的经历。

第一个大坑，就是编码问题，尤其是“utf8”和“utf8mb4”这个天坑。

这事儿得从头说起，早些年，MySQL里的“utf8”编码，它压根就不是真正的UTF-8！它最多只支持每个字符3个字节，这在过去可能够用，因为那时候常用的汉字、英文字符都在这个范围内，但问题是，UTF-8是支持1到4个字节的，像一些emoji表情符号（）、还有某些特殊的汉字,需要4个字节来存储。

结果你就猜吧，当你兴高采烈地用着所谓的“utf8”字符集，然后用户在前端输入了一个emoji，准备存进数据库——啪唧！报错了，类似“Incorrect string value”这种，你当时肯定懵了，心想：“我明明设置的是UTF-8啊，全球通用，怎么会存不进去？” 你查遍代码，怀疑人生，最后才发现，罪魁祸首是MySQL的这个历史遗留问题，它那个“utf8”是个“阉割版”。

后来MySQL意识到了这个问题，推出了“utf8mb4”这个真正的UTF-8编码，支持4字节字符，现在但凡有新项目，表、字段、连接池的字符集，统统都要设置成utf8mb4，别再用那个假的“utf8”了，但坑爹的是，有时候你导一份老的数据库备份，如果它用的是老的“utf8”，你在新环境里可能还得处理兼容性问题，一不小心就乱码，这个教训就是：永远别相信默认值，建库建表的第一件事，就是明确指定字符集和排序规则（collation），CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。

第二个坑，关于排序规则的，大小写敏感搞得人头晕。

排序规则（collation）这事儿也挺微妙，比如说，常用的 utf8mb4_general_ci 和 utf8mb4_unicode_ci，那个 ci 意思是大小写不敏感（case-insensitive）。general 和 unicode 的区别在于排序的准确度，unicode 更符合Unicode标准，对特殊字符、多种语言的排序更准确，但理论上比 general 慢一丢丢（现在硬件好了，基本可以忽略）。

这听起来挺好，对吧？但坑在哪里呢？如果你建表的时候没注意，有的表是 ci（不区分大小写），有的表是 cs（区分大小写），或者同一个数据库里混着用，那你的SQL查询结果就可能变得神经质，你用户注册时，用户名是ZhangSan，结果另一个用户用zhangsan也能注册成功，因为数据库认为这俩是同一个东西，但如果你在代码里做比较或者用了区分大小写的排序规则，这俩又成了不同的用户，这种不一致性在排查问题时能让你抓狂,感觉数据库在跟你玩玄学。

最好在整个项目里统一排序规则，一般建议用 utf8mb4_unicode_ci，省心，除非你有特殊业务要求,必须区分大小写。

第三个坑，连接池的编码设置，光数据库那头设置了没用。

这个坑我印象太深了，当时我们明明把数据库、表、字段的字符集全都改成utf8mb4了，满以为高枕无忧，结果呢，线上环境一跑，还是有乱码，折腾了好久，最后发现是应用程序连接数据库的时候，连接字符串（JDBC URL）里没指定字符集！

你想啊，数据传递的路径是：应用服务器 -> 数据库连接 -> MySQL服务器，你光把终点（MySQL服务器）的规矩定好了，但运送数据的“高速公路”（连接）本身用的还是老标准（比如latin1），那数据在路上就已经被转码转乱了,到数据库里再怎么纠正也白搭。

在连接字符串里一定要加上字符集参数，比如Java的JDBC连接，就要在URL后面显式加上 ?characterEncoding=utf8（注意，这里写utf8没问题，驱动会识别成utf8mb4，或者你也可以直接指定utf8mb4，取决于驱动版本），这相当于给数据运输通道也上了保险，很多框架的配置文件里容易忽略这个参数,一不留神就中招。

第四个坑，索引长度限制，和utf8mb4联手挖的坑。

我们知道，InnoDB引擎对单列索引的长度是有限制的（通常是767字节），在老的“utf8”编码下，一个字符占3个字节，varchar(255) 的字段，索引最大长度是 255 * 3 = 765字节，刚好小于767，所以你能给varchar(255)建索引。

但换到utf8mb4后，一个字符最多占4个字节，这时候你再给varchar(255)建索引，理论最大长度就变成了255 * 4 = 1020字节，远远超过了767的限制,直接报错。

解决方法要么是减小字段长度，比如改成varchar(191)（因为191 * 4 = 764 < 767），要么就是启用innodb_large_prefix配置（MySQL 5.7.7以后默认开启）来扩大限制，但你在做表结构变更或数据迁移时，如果没想到这一层，索引创建失败会让你措手不及，这就提醒我们，修改字符集不是简单地改个配置，要连带检查索引是否受影响。

第五个坑，数据传输和终端显示中的乱码。

你数据库里面存的数据是对的，但通过命令行客户端查出来是乱码，这往往是因为你的终端（比如Linux的shell或者Windows的CMD）的编码设置和数据库返回的编码不匹配，数据库返回的是UTF-8，你的终端可能默认是GBK或者其他编码,显示出来自然就乱了。

还有一种情况是，你从一个UTF-8的数据库里导出的SQL文件，在导入到另一个环境时，如果没注意导入命令的字符集设置，也可能导致乱码。操作数据库时，要确保客户端、终端、导入导出工具的编码环境保持一致，都是UTF-8阵营的。

MySQL的编码问题就像房间里的大象，看似简单，但细节太多，核心心法就是：从源头（客户端应用）到通道（连接）再到终点（数据库服务器、表、字段），所有环节的字符集设置必须保持统一，最好是全线使用utf8mb4，别偷懒，每个环节都明确指定，才能最大程度地避免这些坑，这些经验，真是在一次次深夜报警和焦头烂额的排查中,才真正刻进脑子里的。