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等子句中，可对具体表达式显式指定排序规则，它会覆盖字段本身和数据库默认设置：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 例如：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_cs vs utf8mb4_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%的问题当场定位。