mysql 数据库与表的字符集设置问题

[labilixin]

今天团队里有一个人纠结字符集设置问题。说排序规则不要使用 utf8mb4_0900_ai_ci 。

后来了解他说是要和数据库的字符集与排序规则一致。数据采用的排序规则是 utf8mb4_bin 。

msyql8.0 默认就是 utf8mb4_0900_ai_ci 。所以会出现不一致的问题。

引起了我的好奇。我上网查询字符集设置的一些内容。说是字符集不一致会影响排序结果、索引、和 join 查询等。

但是帖子说的大多都是两张表不一致会影响 join 查询。可是我自己测试的时候却没有影响。

最后虽然我没有测试出来效果，但是感觉还是保持一致比较合理。这里想问一下大家。

1 、数据库的字符集和排序规则和表的字符集排序规则有没有关系。有没有互相影响？
2 、还是说只有表和表之间的字符集不一致才会有影响？

[zhangshaohan]

有影响，生产上遇到过

[Ketteiron]

A 表 B 字段 joinC 表 D 字段，select * from A 两个字段的排序规则需要一致，所以最好统一全部数据库字段的排序规则，有特殊需求的字段再另外调整，同时注意这个字段和其它字段 join 时会不会出问题。
另外可以配置成不同的排序规则也允许 join ，但是一般不建议这么做，或者查询时指定成相同的排序规则，但是本来就屎山的长 sql 会更加恶心

[vaynecv]

遇到过一个场景，两张表数据量不大的情况下，联表查非常慢，最终定位下来的原因就是两个关联字段的字符集设置不同😅

[LiaoMatt]

字符集和排序规则有四个维度, 服务器, 数据库, 表, 列;字符集主要是影响存储在磁盘的数据是怎么样的, 排序规则则决定了 B+树如何排序, 如果排序规则不一样, 会影响查询的效率, 比如我用 A 排序, 在一页内连续的数据在另一个索引上使用了排序 B, 导致数据是分散的, 数据的读取从顺序 IO 变成了随机 IO, 效率会低很多

[yrzs]

前几天刚遇到 utf8mb4_0900_ai_ci 不会区分字符大小写，utf8mb4_bin 会区分

[NeedI09in]

不同字符集在联表查询时会进行隐式转换。包括 int 和 str

[cnoder]

字符集和排序有两个关键词 chatset 和 collect ，一般人只关心 chatset ，你再了解下 collect 就懂了

[dt1]

最近遇到一个类似的问题，发现这个区别的影响，查到此处，把这个坑也提上来记到此处，供其他人遇到时参考：
1. 使用 ai_ci 是不区分生意和大小写的（针对外文的场景），而编程语言一般是精确匹配，这会导致数据库的查询与编程语言的处理不一致，存在出错的隐患。
2. ai_ci 适合于非中文的字符的更面向交流习惯的匹配，对于中文的应用，关联的可能是一些编码之类的查询匹配。比如一般认为不同大小写的应该视为同一个编码（但这也看具体业务），则基于 ai_ci 时不区分大小写或相视性都算匹配（比如有一些音重的字符看起来是同一个字符，但是顶上是带重音符号的，按存储编码是不一致的）。
3. 我个人推荐使用 utf8mb4_bin ，这样跟应用程序的处理逻辑一致，使得处理时不要考虑太多。对于特别需要处理的场景，再针对指定的字符指定特殊的字符集，比如针对不区分编码类的，要使用数据库 sql 进行检索的，使用 utf8mb4_0900_ai_ci 。但是是作为特殊场景存在。

问题来源：
我们这回出问题的，是因为检索时使用 sql 进行检索，然后发现存在。但实际上大小写不一致。然后检索匹配的数据在后续语言处理中出现了问题，在编程语言中是区分大小写的，就出错了。考虑这是一个通用的场景和问题，而且感觉还有出现类似问题的可能（开发人员不一定有这种意识），所以有上面的评估考虑。