sql排序规则分四层:字段定义(最基础)、查询级显式指定(优先级最高)、连接比较时对齐、系统配置(仅影响新建对象);需按“在哪设、谁优先、怎么冲突”排查问题。

SQL排序规则(Collation)决定字符串比较、排序和存储时的字符行为,比如大小写是否敏感、是否区分重音、使用哪种语言规则等。它不是简单加个ORDER BY就能搞定的事——真正影响结果的是字段定义、连接上下文、查询级显式指定三者共同作用的结果。掌握它的核心,在于理清“在哪设、谁优先、怎么冲突”这三点。
字段定义层:建表时就定下默认行为
这是最基础也最持久的一层。当你创建字段时指定COLLATE,它就成了该列的默认排序规则:
- 例如:
name VARCHAR(50) COLLATE utf8mb4_unicode_ci—— 表示该列默认按 Unicode 规则排序,不区分大小写(_ci)、不区分重音 - 若建表时完全没写
COLLATE,则继承所在数据库的默认排序规则(可通过SHOW CREATE database db_name查看) - 修改已有列的排序规则需用
ALTER table ... MODIFY column或CHANGE COLUMN,会触发表重建,生产环境慎用
查询执行层:运行时可临时覆盖,优先级最高
在ORDER BY、WHERE、GROUP BY等子句中,可对具体表达式显式指定排序规则,它会覆盖字段本身和数据库默认设置:
- 例如:
select * FROM users ORDER BY name COLLATE utf8mb4_bin;—— 即使name列是_ci,这里强制按二进制字节排序(区分大小写+重音) - 多字段排序时可混用:
ORDER BY last_name COLLATE utf8mb4_general_ci, first_name COLLATE utf8mb4_bin - 注意:
COLLATE只能用于字符串类型字段或表达式;数值、日期字段不支持
连接与比较场景:隐式转换常成“隐形陷阱”
当两个不同排序规则的字符串参与比较(如JOIN、WHERE a.col = b.col),mysql / SQL Server 等会尝试自动转换,但规则复杂且易出错:
- MySQL 中,若两边排序规则不同且不可兼容(如
utf8mb4_0900_as_csvsutf8mb4_bin),会报错Illegal mix of collations - 常见诱因:临时表字段继承了会话默认规则,而原表用的是库级规则;或函数返回值(如
CONCAT())未显式指定COLLATE - 稳妥做法:在关键比较前统一转:
WHERE a.name COLLATE utf8mb4_unicode_ci = b.name COLLATE utf8mb4_unicode_ci
系统级配置:影响新建对象的起点,但不改变已有结构
数据库实例、库、甚至客户端连接都有默认排序规则层级,它们只决定“新创建对象”的默认值,不影响已存在字段:
- 查看当前库默认规则:
SELECT DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db'; - 建库时指定:
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 连接时指定(如 MySQL):
SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci;,仅影响该连接后续语句的默认解析行为
基本上就这些。排序规则不是玄学,而是分层生效的明确逻辑链:字段定义打底 → 查询显式调用盖章 → 比较时按需对齐 → 系统配置只管“出生证”。遇到乱序、查不到、报错,顺着这个链条一级级查,90%的问题当场定位。