mysql8 utf8mb4字符集的排序规则

一、命名规则解析

这些 utf8mb4 排序规则的命名遵循统一格式：utf8mb4_[Unicode版本]_[重音规则]_[大小写规则]

• 0900：指 Unicode 9.0.0 标准，是 MySQL 8.0 引入的新版排序规则，比旧版更准确。
• ai / as：
  • ai = Accent Insensitive（不区分重音）
  • as = Accent Sensitive（区分重音）
• ci / cs：
  • ci = Case Insensitive（不区分大小写）
  • cs = Case Sensitive（区分大小写）
• bin：Binary，直接按字符的二进制编码值比较，最严格。
• 带语言名（如 croatian_ci、czech_ci）：针对特定语言的排序规则，遵循该语言的字母表和排序习惯。

二、核心规则对比

三、典型场景差异

• A 和 a：
  • _ci 规则下视为相等；_cs 和 bin 规则下视为不同。
• é 和 e：
  • _ai 规则下视为相等；_as 和 bin 规则下视为不同。
• 排序顺序：
  • _bin 按编码值排序，可能不符合人类阅读习惯；
  • 0900 系列按 Unicode 9.0 标准排序，更符合多语言场景。

四、选择建议

• 通用业务场景：优先使用 utf8mb4_0900_ai_ci（默认），兼容性和易用性最好。
• 需要严格区分重音或大小写：选择 utf8mb4_0900_as_ci 或 utf8mb4_0900_as_cs。
• 密码、哈希等敏感字段：使用 utf8mb4_bin，避免因排序规则导致的安全问题。
• 特定语言应用：选择对应语言的排序规则（如 utf8mb4_croatian_ci）。

五、 通用业务场景（绝大多数项目）

• 推荐规则：utf8mb4_0900_ai_ci
• 适用场景：
  • 用户昵称、用户名、商品名称、文章标题等
  • 中文、英文混合的普通文本存储与查询
• 优势：
  • 不区分大小写（A = a）
  • 不区分重音（é = e）
  • 符合 Unicode 9.0 排序，兼容性最好，是 MySQL 8.0 默认值

需要区分重音的场景

• 推荐规则：utf8mb4_0900_as_ci
• 适用场景：
  • 多语言人名、地名（如法语、西班牙语、德语等带重音的语言）
  • 需要精确匹配重音字符的业务逻辑
• 特点：
  • 区分重音（é ≠ e）
  • 不区分大小写（A = a）

需要严格区分大小写和重音的场景

• 推荐规则：utf8mb4_0900_as_cs
• 适用场景：
  • 敏感字段校验（如验证码、唯一标识码）
  • 严格的多语言文本比对
• 特点：
  • 区分重音（é ≠ e）
  • 区分大小写（A ≠ a）
  • 遵循 Unicode 9.0 排序规则

密码、哈希等敏感字段

• 推荐规则：utf8mb4_bin
• 适用场景：
  • 密码哈希、API Key、Token、唯一哈希值
• 特点：
  • 直接按二进制编码值比较，不遵循任何语言或 Unicode 排序
  • 完全区分大小写和重音，避免排序规则导致的安全隐患

特定语言本地化场景

• 推荐规则：对应语言的规则，如：
  • 克罗地亚语：utf8mb4_croatian_ci
  • 捷克语：utf8mb4_czech_ci
  • 丹麦语：utf8mb4_danish_ci
  • 西班牙语：utf8mb4_es_0900_ai_ci / utf8mb4_es_0900_as_cs
• 适用场景：
  • 面向特定语言用户的应用，需要严格遵循该语言的字母表和排序习惯
  • 本地化排序、搜索、索引优化

旧项目兼容场景

• 推荐规则：
  • 若从 MySQL 5.7 升级，旧默认 utf8mb4_general_ci 可逐步迁移到 utf8mb4_0900_ai_ci
  • 若需保持完全兼容，可临时使用 utf8mb4_general_ci，但建议长期迁移
• 注意：
  • utf8mb4_general_ci 是旧版规则，排序准确性不如 0900 系列，且不支持最新 Unicode 字符

六、具体业务（比如是做电商、社交、还是后台管理系统）

一、先明确核心适配逻辑

我会按「通用型后台管理系统」「电商平台」「社交类应用」「多语言跨境应用」4 类主流业务场景，给出开箱即用的配置方案，你可直接对应自己的业务类型选用。

二、分场景定制配置方案

1. 通用型后台管理系统（企业内部 / ToB 系统）

核心需求：简单稳定、兼容中文 / 英文，查询便捷

配置示例（MySQL 建表）：

CREATE TABLE sys_user (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL,
  password VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,
  remark VARCHAR(200) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

2. 电商平台（零售 / 商城）

核心需求：商品搜索友好、订单 / 支付字段精准

配置示例（MySQL 建表）：

CREATE TABLE goods (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  goods_name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL,
  order_sn VARCHAR(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs NOT NULL UNIQUE,
  customer_name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_ci DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

3. 社交类应用（社区 / 聊天 / 内容平台）

核心需求：内容搜索灵活、用户昵称友好

4. 多语言跨境应用（外贸 / 海外版 APP）

核心需求：适配本地化排序、精准区分语言特征

三、全局配置优化建议

1. 数据库级别统一配置（避免逐表配置）：

-- 创建数据库时指定默认规则
CREATE DATABASE your_db_name 
DEFAULT CHARACTER SET utf8mb4 
DEFAULT COLLATE utf8mb4_0900_ai_ci;
 
-- 已有数据库修改默认规则
ALTER DATABASE your_db_name 
DEFAULT CHARACTER SET utf8mb4 
DEFAULT COLLATE utf8mb4_0900_ai_ci;

1. 特殊字段单独指定：仅密码、流水号、敏感校验字段需单独指定bin/as_cs，其余复用库默认即可。
2. 升级兼容：从 MySQL 5.7 升级的项目，先保留utf8mb4_general_ci过渡，逐步迁移到utf8mb4_0900_ai_ci（更精准）。

总结

1. 通用场景优先选utf8mb4_0900_ai_ci，是兼容性和易用性的最优解；
2. 敏感字段（密码 / 流水号）必须用utf8mb4_bin或utf8mb4_0900_as_cs，避免规则导致的匹配漏洞；
3. 多语言场景按本地化需求选对应语言规则，而非通用规则，提升用户体验。

到此这篇关于mysql8 utf8mb4字符集的排序规则的文章就介绍到这了,更多相关mysql8 utf8mb4字符集排序内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！