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%的问题当场定位。
