MySQL默认不支持汉字拼音首字母排序，需用COLLATE utf8mb4_0900_as_cs或应用层预计算首字母；CONVERT(...USING gbk)仅巧合有效且不可靠，因GBK非严格拼音序，且易致乱码或截断。
MySQL 默认不支持按汉字拼音首字母排序，直接用 ORDER BY 会按字符编码（如 utf8mb4 的 Unicode 码位）排，导致“张”“李”“王”乱序；必须借助 CONVERT 或更稳妥的 COLLATE 显式指定中文排序规则。
为什么 CONVERT(col USING gbk) 有时能“凑效”，但不可靠
早期有人用 CONVERT(name USING gbk) 再配合 ORDER BY，是因为 GBK 编码下汉字大致按拼音顺序排列（如“阿”在前、“做”在后）。但这只是巧合：
- GBK 并非严格拼音序，存在大量例外（如“区”“曲”“戚”等字在 GBK 中位置错乱）
- MySQL 8.0+ 默认字符集为
utf8mb4，强制转gbk可能触发隐式截断或乱码（尤其含 emoji 或生僻字时） -
CONVERT(... USING gbk)不改变排序逻辑，仅转换存储字节；真正起作用的是后续是否搭配了支持拼音比较的COLLATE
正确做法：用 COLLATE 指定支持拼音的排序规则
MySQL 5.7.17+ 和 8.0+ 原生支持 utf8mb4_unicode_ci，但它按 Unicode 排序，仍不是拼音。真正可用的是：
- MySQL 8.0+：使用
utf8mb4_0900_as_cs（区分大小写、重音、口音），对简体中文基本按拼音首字母分组（非严格全拼音排序，但首字母稳定） - 更推荐：显式提取首字母再排序 —— 先用函数获取汉字首字母，再按字母排序
例如获取首字母并排序：
SELECT name,
LEFT(CONVERT(name USING gbk), 1) AS first_byte,
ELT(INTERVAL(CONV(HEX(LEFT(CONVERT(name USING gbk), 1)), 16, 10),
0xB0A1, 0xB0C5, 0xB2C1, 0xB4EE, 0xB6EA, 0xB7A2, 0xB8C1, 0xB9FE, 0xBBF7, 0xBFA6, 0xC0AC, 0xC2E8, 0xC4C3, 0xC5B6, 0xC5BE, 0xC6DA, 0xC8BB, 0xC8F6, 0xCBFA, 0xCEDA, 0xCEF4, 0xD1B9, 0xD4D1),
'A','B','C','D','E','F','G','H','J','K','L','M','N','O','P','Q','R','S','T','W','X','Y','Z') AS pinyin_first
FROM users
ORDER BY pinyin_first, name;
这段逻辑依赖 GBK 区位码映射表，虽兼容性尚可，但维护成本高、易出错。
生产环境建议：在应用层或生成列中预计算拼音首字母
数据库层硬做拼音排序，性能差、可读性低、升级易断裂。更务实的做法：
- 新增
pinyin_first字段（CHAR(1)），用应用代码（Python/Java）调用pypinyin或hutool生成首字母，写入时维护 - MySQL 5.7+ 可建虚拟生成列：
ALTER TABLE users ADD COLUMN pinyin_first CHAR(1) AS (get_pinyin_first(name)) STORED;，但需自定义函数（需启用log_bin_trust_function_creators） - 若必须纯 SQL，优先用
COLLATE utf8mb4_0900_as_cs配合SUBSTR()截取首字符再排序，它对大多数简体中文姓名首字母分组足够稳定
真正麻烦的不是怎么写一行 CONVERT，而是 GBK 编码映射表没人校验、MySQL 版本升级后 COLLATE 行为变化、以及多音字（如“重庆”的“重”该算 C 还是 Z）——这些都得在业务逻辑里兜底。
