MySQL "<" 结果不一致解析：字符集排序规则陷阱

2025-01-03 11:44:33

MySQL 中 "<" 操作符结果不一致的问题解析

在 MySQL 中，使用 “<” 操作符进行字符串比较时，有时会遇到在不同场景下结果不一致的情况。虽然看起来比较简单，但这个问题的根源往往在于字符集排序规则的细微差异。接下来我们将深入分析并给出解决方案。

问题

如下SQL语句，在MySQL 8.0 中运行，在预期中 SELECT * FROM t1 WHERE (s < '0002:') 会返回 ‘0001/a’, '0001/b', '0002/a', '0002/b’，但实际上只会返回 ‘0001/a’, '0001/b’。单独进行的 '0002/a' < '0002:' 和 '0002/b' < '0002:' 的结果均为 true, 但是在WHERE 条件中，实际的过滤却与单独比较的结果不一致。

DROP TABLE IF EXISTS t1;

CREATE TABLE
    t1 (s VARCHAR(10));

INSERT INTO
    t1 (s)
VALUES
    ('0001/a'),
    ('0001/b'),
    ('0002/a'),
    ('0002/b'),
    ('0003/a'),
    ('0003/b');

SELECT ('/' < ':');

SELECT ('0002/a' < '0002:');

SELECT ('0002/b' < '0002:');

SELECT * FROM t1 WHERE (s < '0002:');

这种不一致的行为非常反直觉，甚至让人怀疑是否是MySQL的错误。问题关键在于字符集的排序规则，在比较过程中 MySQL 根据特定规则比较字符串，而这些规则可能会随着使用环境有所变化。

问题分析

具体来说，当在查询中使用 < 比较操作符时，MySQL 8.0 默认使用 utf8mb4_0900_ai_ci 的排序规则，其中 ‘/’ 的排序高于 ‘:’，这是导致问题的核心原因。而单独执行的 SELECT 语句，因为 context 上略有区别，使用的排序规则稍有不同，表现为字符 “/” 比 “:” 小。这个细微的区别直接影响了 < 操作符的结果。数据库、表、列以及连接等不同的配置和环境都可能会影响使用的 collation。COLLATION 用于定义比较字符串时的排序和字符规则。

以下是 show variables like "%collat%" 的结果：

+-------------------------------+--------------------+
| Variable_name                 | Value              |
+-------------------------------+--------------------+
| collation_connection          | utf8mb3_general_ci |
| collation_database            | utf8mb4_0900_ai_ci |
| collation_server              | utf8mb4_0900_ai_ci |
| default_collation_for_utf8mb4 | utf8mb4_0900_ai_ci |
+-------------------------------+--------------------+

可以看出，连接层和数据库层的 collation 不同。单独的比较语句使用的collation和数据层面的查询略有不同。

解决方案

有几种方式可以解决这类排序规则引发的不一致问题。选择方案时，需要结合具体场景和对系统影响来权衡。

方案一：统一使用相同的 collation

最直接的方法是确保查询和比较中使用相同的 collation。在数据表设计时就明确 collation 选项可以减少这类问题的发生。可以强制为所有字符串比较操作应用相同的 COLLATE 子句，这样就使得所有 WHERE 条件下的字符串比较使用同样的 collation 规则。这个方案需要更改查询语句，但对原有数据结构不做修改，应用成本较低。

SELECT * FROM t1 WHERE (s < '0002:' COLLATE utf8mb4_general_ci);

上面的查询使用了 utf8mb4_general_ci 规则，与单独的比较一致。使用该 collation 结果符合预期：

+--------+
| s      |
+--------+
| 0001/a |
| 0001/b |
| 0002/a |
| 0002/b |
+--------+

方案二：修改表默认 collation

另一种解决办法是直接更改数据表的 collation。修改表的默认排序规则后，所有在该表上进行的字符串比较都将采用新的 collation。注意，这可能会影响表内数据的存储方式以及涉及到该表索引的比较行为，在修改前请务必仔细评估。更改表 collation 后需要使用 OPTIMIZE TABLE table_name; 来重构数据和索引。

以下 SQL 演示如何修改数据表默认 collation：

ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
OPTIMIZE TABLE t1;

SELECT * FROM t1 WHERE (s < '0002:');

这个方案调整了数据表的结构，需要考虑 collation 的更改带来的影响，对大型数据库的修改影响较大，修改需要规划窗口时间。使用新的 collation 后结果同样符合预期。

+--------+
| s      |
+--------+
| 0001/a |
| 0001/b |
| 0002/a |
| 0002/b |
+--------+

方案三：修改 server collation

此方法更改 server 级别的 collation, 可以直接影响所有新创建的 database 和 tables。对服务器级别产生影响较大，通常仅当数据库整体 collation 设计与预期存在较大偏差时才考虑采用此方法，请慎重执行。修改 collation 之后，新的数据库会使用新的设置，之前已经建立的数据库和表并不会被修改。如果想让已有的数据库和表也生效，需要分别执行上述针对 database 和 table 的 ALTER 语句。

mysql -u root -p

SET GLOBAL collation_server = 'utf8mb4_general_ci';
SET GLOBAL collation_connection = 'utf8mb4_general_ci';
exit

# 通过 --init-file 执行 server startup script
docker run -d -p 3306:3306 --name mysql \
  -e 'MYSQL_DATABASE=t' \
  -e 'MYSQL_ROOT_PASSWORD=password' \
    -v $(pwd)/my.cnf:/etc/my.cnf \
  --restart always mysql

其中my.cnf 内容如下：

[mysqld]
collation-server=utf8mb4_general_ci
init-connect='SET collation_connection = utf8mb4_general_ci'

执行后，再次使用上述sql，可以观察到期望的结果：

+--------+
| s      |
+--------+
| 0001/a |
| 0001/b |
| 0002/a |
| 0002/b |
+--------+

额外安全建议

保持collation的一致性 ：强烈建议在创建数据库、表或连接时，统一字符集和 collation 配置。这将减少因为 collation 不一致而产生的问题。
仔细检查比较规则 : 在执行复杂的字符串比较操作前，检查 collation 设置非常必要，不同 collation 对结果可能产生严重影响。

总结

当MySQL在不同环境使用字符串进行比较操作时，字符集排序规则可能产生不可预测的影响。理解MySQL如何使用collation及其差异对于避免类似问题至关重要。通过统一 collation 设置或者在查询中强制指定 COLLATE 子句，能够解决 < 操作符结果不一致的问题。请根据实际应用场景，谨慎选择最合适的方案。