SQL排序规则（Collation）决定字符串比较与排序行为，影响查询顺序、WHERE匹配及索引效率；需按数据库查看当前规则，针对中文排序、大小写/重音处理等场景合理设置局部或全局collation，并避免JOIN冲突、函数隐式转换等常见问题。
SQL排序规则（Collation）决定字符串如何比较和排序，比如大小写是否敏感、是否区分重音符号、按什么语言习惯排序等。设置对查询结果顺序、WHERE条件匹配、索引效率都有直接影响，不能只靠默认值应付。
一、查看当前排序规则
不同数据库语法略有差异，但核心思路一致：
-
MySQL：查库、表、列级 collation
SHOW VARIABLES LIKE 'collation_database';
SHOW CREATE TABLE user_info;（看字段定义里的 COLLATE 子句） -
SQL Server：查实例、数据库、列级
SELECT DATABASEPROPERTYEX('MyDB', 'Collation');
SELECT name, collation_name FROM sys.columns WHERE object_id = OBJECT_ID('users'); -
PostgreSQL 不叫 collation 而叫 “LC_COLLATE”，在创建数据库时指定，后续字段可单独用 COLLATE 子句覆盖：
SELECT datcollate FROM pg_database WHERE datname = 'mydb';
二、常见高频场景与设置方法
不是所有场景都要改全局规则，灵活用好“局部覆盖”更安全高效：
-
中文按拼音排序（MySQL/SQL Server）
MySQL 示例：ORDER BY name COLLATE utf8mb4_unicode_ci（支持拼音排序的 Unicode 规则）；
SQL Server 更推荐：ORDER BY name COLLATE Chinese_PRC_CI_AS（专为简体中文优化）。 -
忽略大小写但区分重音（如 é ≠ e）
MySQL 可用：utf8mb4_0900_as_cs（accent-sensitive + case-sensitive）；
若要忽略大小写但保留重音区分，选：utf8mb4_0900_as_cs → 改为 utf8mb4_0900_as_ci（ci = case-insensitive）。 -
临时让某次查询不区分大小写匹配
不用改表结构，WHERE 中直接加 COLLATE：
WHERE email COLLATE utf8mb4_general_ci = 'ADMIN@EXAMPLE.COM'；
比 LOWER(email) = LOWER('ADMIN@EXAMPLE.COM') 更易走索引（前提是该列有对应 collation 的索引）。
三、建表/改字段时指定排序规则
预防胜于补救，关键字段建议显式声明 collation：
- MySQL 创建字段：
name VARCHAR(50) COLLATE utf8mb4_unicode_ci NOT NULL - SQL Server 修改列：
ALTER TABLE users ALTER COLUMN username NVARCHAR(50) COLLATE SQL_Latin1_General_CP1_CI_AS; - PostgreSQL 字段级 collation（9.5+）：
SELECT * FROM products ORDER BY product_name COLLATE "en_US";
或建表时：product_name TEXT COLLATE "zh_CN"（需系统 locale 支持）。
四、避坑提醒：这些情况容易出错
排序规则不一致常导致隐式转换、报错或结果异常：
- 两张表 JOIN 时字段 collation 不同 → 报错 "Cannot resolve collation conflict"；解决：JOIN 条件中统一用 COLLATE 显式转，或建索引前统一字段规则。
- 函数结果无 collation 继承（如 CONCAT、UPPER）→ 默认用数据库级规则，可能和原字段不兼容；建议显式追加 COLLATE。
- 迁移数据到新库时忽略 collation 设置 → 中文排序乱、搜索不命中；导出前先查源库 collation，目标库建库时指定相同 LC_COLLATE 或 collation_name。
基本上就这些。排序规则不是越复杂越好，关键是匹配业务语义——用户搜“iPhone”，应该匹配“iphone”也匹配“Iphone”；但财务系统里“USD”和“usd”是否等价，得由业务定。设对一次，省去无数模糊排查。
