江苏龙网

  1. 首页 > 生活 > >

「升级」升级MySQL 8.0的诡异故障，utf8mb4_0900_ai_ci是什么？( 二 )


所以，utf8mb4_0900_ai_ci到底是个什么东西呢？其实，它是个collation。
说起“字符集”，许多人想当然认为，给每个字符分配了一个编码，并且能存储、能传输，这就够了。其实这当然不够，我们不但需要给每个字符分配编码，让它们能存储、能传输，还需要定义一套关系来组织它们，找到它们之间的联系。这套关系的定义，就是collation。
collation定义了哪个字符和哪个字符是“等价”的。所以如果指定“不区分大小写”，那么a和A，e和E就是等价的，这样查找时就会方便很多。但这还不够，世界上的文字很多，所以才会有“不区分音调”的要求，这时候e、ē、é、ě、è就是等价的，那么假设我们要进行拼音查找，只要按e去找就可以全部列出来，很方便。甚至，它们也和ê、?也是等价的，这样就更方便了。
collation也定义了字符的排序规则，如果按照“字符顺序（而不是简单的‘字母顺序’）”来排序，哪个字符应当排在哪个字符前面。所以，尽管“啊”、“副”、“德”三个字的拼音开头分别为A、F、D，但直接选定collation为utf8mb4，它们并不会按照“啊”、“德”、“副”的顺序排序，而是会排成“副”、“啊”、“德”。如果你希望把中文字符按照拼音来排序，指定使用gb18030_chinese_ci作为collation就可以了。
当然，要补充的是，collation依赖于字符集（character set），所以把gb18030_chinese_ci作为collation，就要求字符集是gb18030，而不能是utf8mb4。
这也很好理解，字符集定义了可以使用的字符，对应的collation定义了字符之间的关系。如果collation不依赖于字符集，那么很可能出现“有些字符没有关系定义，不知如何判断等价和顺序”的问题。
到这里，那位朋友的疑惑就解开了。MySQL 8.0之后，默认collation不再像之前版本一样是是utf8mb4_general_ci（这个名字也确实取得有问题，话说得太满，有点自负了），而是统一更新成了utf8mb4_0900_ai_ci。
不幸的是，这位朋友的系统是一路升级上来的，所以之前建的各种数据表，它们的collation仍然是utf8mb4_general_ci，而新建的表是utf8mb4_0900_ai_ci。如果恰好遇到包含字符串相等或者大小比较的联表查询语句，而关联的表又使用了不同的collation，MySQL就无法决策到底应当使用哪个，就会报错。
既然如此，解决办法也很简单，用alter table table_name collate utf8mb4_0900_ai_ci显式统一所有表的collation，问题就解决了。
我们可以多想想，把character set和collation分开，到底有什么好处？其实好处很多。如果把字符看作个人，character set就相当于验明正身，给每个字符发张身份证，而collation相当于告诉大家，排队的时候谁在前谁在后。collation有多套，就相当于可以灵活按身高、体重、年龄、出身地等等因素来排序，却完全不会受到身份证号的干扰。
实际上collation也是如此，既然有utf8mb4_0900_ai_ci，就还有utf8mb4_0900_as_ci和utf8mb4_0900_as_cs。看名字也可以知道，utf8mb4_0900_as_ci表示“区分音调”，所以e、ē、é、ě、è就不再是等价的；而utf8mb4_0900_as_cs表示“区分大小写”，所以查e的时候就不会把E查出来。
这个问题本来不麻烦，为什么会难住人呢？原因不复杂，你去看关于MySQL和Unicode的中文资料，绝大部分都是告诉你，utf8或者utf8mb4就可以解决问题了。因此，不少程序员完全意识不到还有collation这种东西。
所以，这些程序员理解的“字符集”就只有一堆孤零零的字符，根本没想到还需要定义字符之间的等价和排序关系。而这恰恰是最可惜的，因为他们完全错过了“举一反三”的启发，许多类似问题也就缺乏解决思路。要知道，哪怕你做的不是国际化的业务，也可以从collation中受益的。
我们都知道，电商系统的订单处理是一个流程，其中涉及许多状态，比如“已下单，未支付”、“已支付”、“已确认”、“已拣货”、“已发货”等等。


推荐阅读


上一篇： 「客家人」小南瓜怎么做？客家人教你决窍和方法，外焦里嫩，好吃到停不下来

下一篇： 肖战的加■最强大脑最新季开启录制，肖战惊喜加盟人气爆