mysql 5.7及更早版本不支持直接按拼音排序，convert仅转换字符集编码，无法生成拼音或首字母；真正决定排序的是collation，而非convert。
MySQL 5.7 及更早版本不支持直接按拼音排序，CONVERT 函数仅能改变字符集编码，不能生成拼音或首字母——它无法实现你想要的“按拼音首字母排序”效果。
为什么 CONVERT(col USING gbk) 不能用于拼音首字母排序
很多人误以为把字段转成 gbk 编码后，ORDER BY 就会按汉字拼音顺序排，其实这是对字符集和排序规则（collation）的混淆。CONVERT 只改变字节表示，不改变排序行为；真正起作用的是列的 COLLATION。即使转成 gbk，若 collation 是 gbk_chinese_ci，它按部首笔画排序；如果是 utf8mb4_unicode_ci，则按 Unicode 码位排——两者都不等于拼音顺序。
-
CONVERT(name USING gbk)不产生拼音，也不提取首字母 - 执行
ORDER BY CONVERT(name USING gbk)实际仍是依赖当前连接或列的默认 collation - 在 utf8mb4 环境下强行 CONVERT 到 gbk 还可能引发乱码或截断（尤其含 emoji 或生僻字时）
真正可行的 MySQL 拼音首字母排序方案
MySQL 原生无拼音函数，必须借助函数映射或外部处理。最实用的是用 ELT() + LEFT() + CONV() 或预置首字母映射表。但更稳定的做法是：用一个确定的拼音首字母映射函数（如基于常见汉字 Unicode 区间判断）。
- 对单字姓名，可查 Unicode 范围：
一（U+4E00）到龥（U+9FFF）中大部分汉字在gbk下首字节对应 A–Z，但有大量例外（如“女”“绿”“吕”都以 L 开头却不在同一区间） - 推荐做法：建一张轻量级映射表
py_first，含char CHAR(1)和first_letter CHAR(1)两列，只存几百个高频字，覆盖 95% 场景 - 查询时 LEFT JOIN 或用
IFNULL((SELECT first_letter FROM py_first WHERE char = LEFT(name,1)), 'Z')补默认值
MySQL 8.0+ 用户应优先用 COLLATE utf8mb4_0900_as_cs？
不适用。这个 collation 是大小写敏感的 Unicode 排序，仍不是拼音排序。MySQL 官方直到 8.4 仍未内置拼音 collation。若你用的是阿里云 RDS 或腾讯云 TDSQL，部分版本已集成 pinyin 插件，可启用后使用：ORDER BY name COLLATE utf8mb4_pinyin_ci——但这属于扩展能力，非标准 MySQL 行为。
- 确认是否支持：
SELECT * FROM information_schema.COLLATIONS WHERE COLLATION_NAME LIKE '%pinyin%'; - 若返回空，说明未安装插件，
CONVERT再怎么套也无效 - 不要尝试用
CONVERT(name USING utf8mb4) COLLATE utf8mb4_pinyin_ci，因为 CONVERT 不改变 collation 绑定关系
简单场景下的应急写法（仅限中文名且无重音/多音字要求）
如果数据量小、汉字较规范（如员工姓名库），可用以下表达式粗略提取首字母（原理是利用 MySQL 的 WEIGHT_STRING + gbk 编码隐式转换，兼容性差但偶有效）：
ORDER BY
CASE LEFT(CONVERT(name USING gbk), 1) >> 4
WHEN 10 THEN 'A' -- 假设部分区段映射
WHEN 11 THEN 'B'
ELSE 'Z'
END
但该方式不可靠：不同 MySQL 版本、OS 字符集环境、甚至客户端连接参数都会导致结果漂移。线上系统请勿采用。
真正要稳定按拼音首字母排序，要么引入应用层排序（Python/Java 调用 pypinyin 或 HanLP），要么升级到支持拼音插件的云数据库，或者在写入时就计算并持久化 first_letter 字段——CONVERT 不是这条路的起点，而是容易让人误入歧途的岔路口。
