问题描述
我正在处理一个包含不同字符集的表的数据库。由于它是一个大数据库，我想知道它是否会导致性能问题。是的，数据库通常进行的值比较是 JOIN 并完成比较整数，但是除了某些字符集占用的空间更大之外，我们是否会遇到其他性能问题，我们会遇到具有不同字符集的表？
解决方法
如果您使用不兼容的排序规则进行字符串比较，则这些比较不能在字符串列上使用索引。我在对字符串列执行 JOIN 时看到了这种情况，并且连接的表具有不同的排序规则（当然，如果它们也具有不同的字符集，它们也是不同的排序规则）。
但是您说您的连接是在整数列上，而不是在字符串列上。因此，在您的情况下，加入应该不是问题。
如果您的表字符集与会话字符集不匹配，则在对字符串列进行查找时，您也可能会遇到性能问题。
示例：我的表是用 utf8mb4 定义的，但我将会话设置为 utf8，因此字符串文字将是 utf8。似乎是无害的更改，对吗？
mysql> set names utf8;
mysql> explain select * from mytable where text = 'abc123';
+----+-------------+---------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+------+---------------+------+---------+-------+------+----------+-------+
| 1 | SIMPLE | mytable | NULL | ref | text | text | 83 | const | 1 | 100.00 | NULL |
+----+-------------+---------+------------+------+---------------+------+---------+-------+------+----------+-------+
我猜 utf8 字符串 'abc123' 有一个明确的方法可以提升到 utf8mb4 以匹配它所比较的列。
但是，如果我强制使用 utf8mb4 不支持的特定排序规则，我会发现它必须进行表扫描并逐行与行进行比较，而不是索引查找：
mysql> explain select * from mytable where text = 'abc123' collate utf8_general_ci;
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------------+
| 1 | SIMPLE | mytable | NULL | ALL | NULL | NULL | NULL | NULL | 10 | 100.00 | Using where |
+----+-------------+---------+------------+------+---------------+------+---------+------+------+----------+-------------+
隐式排序规则和显式排序规则之间存在差异。假设我将会话设置为使用没有明确的 utf8mb4 路径的内容：
mysql> set names latin1;
mysql> explain select * from mytable where text = 'abc123';
+----+-------------+---------+------------+------+---------------+------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+------+---------------+------+---------+-------+------+----------+-------+
| 1 | SIMPLE | mytable | NULL | ref | text | text | 83 | const | 1 | 100.00 | NULL |
+----+-------------+---------+------------+------+---------------+------+---------+-------+------+----------+-------+
到目前为止一切都很好，但如果我明确说明了排序规则：
mysql> explain select * from mytable where text = 'abc123' collate latin1_general_ci;
ERROR 1267 (HY000): Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (latin1_general_ci,EXPLICIT) for operation '='
最重要的是，您应该使用相同的字符集和排序规则，以使您的生活更轻松。将其用于所有表和会话。
在当今时代，很难想出使用 utf8mb4 以外的任何理由。
附言空间应该不是问题。 UTF-8 字符集允许 多字节字符，但它们不会扩展适合单个字节的字符大小。 UTF-8 是一种可变宽度的字符编码。因此，ASCII 范围 (0-127) 中的字符无论如何都存储在一个字节中。阅读UTF-8 on wikipedia了解详情，它有一个很好的解释。
,MySQL：
对于 zip_code (postal_code)，存储为字符串（CHAR 或 VARCHAR），大多数字符集同样有效。但是，当 JOINing 在这样的列上时，排序规则必须相同。
- 如果相同，则可以使用该列的索引。
- 如果不是，则索引没有用，查询必须扫描整个表。
由于排序规则包含字符集，因此也强制字符集相同。
排序规则的选择相当小。但是，如果字符串中可以有字母（postal_code、country_code 等），则需要决定是否强制表（和用户查询）使用特定大小写。
- 排序规则
..._bin将大小写视为不同：“de”不会匹配“DE”（对于德国）。 - 排序规则
..._ci是“不区分大小写的”，因此它们会匹配。