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

有影响，生产上遇到过

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

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

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

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

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

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

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

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