如何解决在 MySQL 或 Postgres 中使用混合表字符集时是否会出现性能问题?
我正在处理一个包含不同字符集的表的数据库。由于它是一个大数据库,我想知道它是否会导致性能问题。是的,数据库通常进行的值比较是 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
是“不区分大小写的”,因此它们会匹配。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。