utf8mb4_0900_ai_ci是多语言搜索的合理起点，因其基于Unicode 9.0.0标准，对重音（如é/e）和大小写（A/a）均不敏感，能正确处理中文、西欧、阿拉伯、越南文等混合排序与模糊匹配。
为什么 utf8mb4_0900_ai_ci 是多语言搜索的合理起点
MySQL 8.0 默认用 utf8mb4_0900_ai_ci，不是偶然——它基于 Unicode 9.0.0 的 UCA 算法，对重音（如 é/e）、大小写（A/a）都不敏感，且能正确处理中文、西欧、阿拉伯、越南文等混合排序。相比旧版 utf8mb4_unicode_ci 或 utf8mb4_general_ci，它在多语言字段的 WHERE name LIKE '%joão%' 或 ORDER BY surname 中更少出现“漏匹配”或错序。
但要注意：它不适用于需要严格区分大小写或重音的场景（比如用户密码校验、法律文书精确比对），此时应降级为 utf8mb4_0900_as_cs 或显式加 BINARY 修饰。
如何逐层覆盖默认排序规则而不留死角
排序规则继承链是：服务器 → 数据库 → 表 → 列 → 字符串常量。只改其中一层，其他层仍可能按旧规则执行比较，导致查询行为不一致。
- 服务器级（影响所有新建数据库）：在
my.cnf中设置：[mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_0900_ai_ci
- 数据库级（影响后续新建表）：
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 表级（影响后续新建列）：
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 列级（最细粒度，强制生效）：
ALTER TABLE users MODIFY COLUMN name VARCHAR(255) COLLATE utf8mb4_0900_ai_ci;
特别注意：CONVERT TO 会重写整张表，大表需评估锁表时间；MODIFY COLUMN 更安全，但必须重复声明类型（如 VARCHAR(255)），否则会丢失定义。
哪些操作会绕过你设的排序规则？
即使所有层级都设成 utf8mb4_0900_ai_ci，以下情况仍可能触发意外行为：
- 连接未声明字符集：
mysql -u user -p登录后，若没执行SET NAMES utf8mb4;，客户端默认用latin1解析输入，导致搜索WHERE title = 'café'实际传入的是乱码字节 - 索引失效：
COLLATE改变后，原有索引不会自动重建。执行SHOW INDEX FROM users;检查Collation列是否为A（表示可用），否则需ALTER TABLE users DROP INDEX idx_name, ADD INDEX idx_name(name); - 字符串字面量隐式转换：
SELECT * FROM users WHERE name = 'João' COLLATE utf8mb4_bin;这种写法会强制走二进制比较，跳过你设的_ai_ci规则
应用层连接字符串也必须带 ?charset=utf8mb4（如 JDBC 的 useUnicode=true&characterEncoding=utf8mb4），否则 ORM 可能静默降级。
验证排序规则是否真正生效的三个命令
别只信配置文件或建表语句，运行时行为才决定实际效果：
- 查当前连接的规则：
SELECT @@collation_connection, @@collation_database, @@collation_server;—— 三者应尽量一致 - 查某列的实际规则：
SHOW FULL COLUMNS FROM users LIKE 'name';—— 看Collation字段是否为预期值 - 实测比较逻辑：
SELECT 'cafe' = 'café' COLLATE utf8mb4_0900_ai_ci; -- 返回 1；SELECT 'cafe' = 'café' COLLATE utf8mb4_bin; -- 返回 0
最易被忽略的是连接层与列级规则的 mismatch：比如数据库设了 _0900_ai_ci，但某个 email 列仍用 utf8mb4_bin（为兼容旧唯一约束），这时对该列做 LIKE 搜索就会大小写敏感——这种混合配置必须文档化，否则半年后没人记得为什么搜索突然不认大写了。
