池建强的MacTalk发布了一篇文章：永远不要在 MySQL 中使用「utf8」
后找到原文：记住，永远不要在MySQL中使用“utf8”编码
发现这确实是一个误区~没有深入了解差别的人，还真的会出问题，用了默认的utf8。
公众号的文章推荐用utf8mb4字符集，我查阅了一些前人的分享，如下是整理的相关信息：
MySQL里实现的utf8最长使用3个字节，也就是只支持到了 Unicode 中的 基本多文本平面 （U+0000至U+FFFF），包含了控制符、拉丁文，中、日、韩等绝大多数国际字符，但并不是所有，最常见的就算现在手机端常用的表情字符 emoji和一些不常用的汉字。
而标准的 UTF-8 字符集编码是可以用 1~4 个字节去编码21位字符。这就导致用了utf8字符串的数据库是有一些字符写不进去的情况发生。
MySQL在 5.5.3 之后增加了 utf8mb4 字符编码，mb4即 most bytes 4。简单说 utf8mb4 是 utf8 的超集并完全兼容utf8，能够用四个字节存储更多的字符。
所以，建议数据库的字符集和程序连接时set的字符集，都指定为utf8mb4。
那么第二个问题来了，utf8mb4_ unicode_ ci 与 utf8mb4_ general_ ci 如何选择，这俩有什么差别？
主要从排序准确性和性能两方面看：
- 准确性
utf8mb4_unicode_ci是基于标准的Unicode来排序和比较，能够在各种语言之间精确排序
utf8mb4_general_ci没有实现Unicode排序规则，在遇到某些特殊语言或字符是，排序结果可能不是所期望的。
但是在绝大多数情况下，这种特殊字符的顺序其实并不太需要这么精确 - 性能
utf8mb4_general_ci在比较和排序的时候更快
utf8mb4_unicode_ci在特殊情况下，Unicode排序规则为了能够处理特殊字符的情况，实现了略微复杂的排序算法。
但是在绝大多数情况下，不会发生此类复杂比较。general理论上比Unicode可能快些，但相比现在的CPU来说，它远远不足以成为考虑性能的因素，索引涉及、SQL设计才是。
我个人推荐是utf8mb4_unicode_ci将来 8.0 里也极有可能使用变为默认的规则。
至此，反正心里有个数，选utf8mb4就对了，至于二者选哪个，我一直习惯utf8_general_ci，所以打算忽略建议。
以上相关信息摘录整理自：mysql使用utf8mb4经验吐血总结
suoyi
如您从本文得到了有价值的信息或帮助，请考虑扫描文末二维码捐赠和鼓励。
如本文对您有用，捐赠和留言 将是对我最好的支持~（捐赠可转为站内积分）
如愿意，请向朋友推荐本站，谢谢。
尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。
留言