convert不能实现中文拼音首字母排序，它仅做字符集转换，真正起作用的是collation；应使用utf8mb4_0900_as_cs等支持拼音比较的校对规则，或预计算拼音首字母存入新列。
CONVERT 不能可靠实现中文分组后的拼音首字母排序，它只是字符集转换函数，不生成拼音、也不影响分组逻辑——真正起作用的是 COLLATION，不是 CONVERT。
为什么 CONVERT(name USING gbk) 在 GROUP BY 后排序会失效
很多人写 GROUP BY CONVERT(name USING gbk) 或 ORDER BY CONVERT(name USING gbk)，以为能按拼音首字母分组+排序，结果发现“李”“刘”“林”全挤在一组、“张”“赵”“周”排在一起。这不是数据问题，是理解偏差：
-
CONVERT只做字节重编码，不提取语义（比如拼音）；GBK 编码下汉字位置是历史兼容设计，不是拼音索引，“区”“曲”“戚”在 GBK 中根本不在同一拼音段 - MySQL 的
GROUP BY依赖列值的二进制等价性，CONVERT(name USING gbk)返回的是 GBK 字节串，但若原始字段是utf8mb4，隐式转换可能截断或填充0x00，导致不同汉字被 hash 成相同值 - 即使排序看起来“差不多”，那也只是巧合——MySQL 5.7 中用
CONVERT(... USING gbk)排序，本质仍是依赖列定义的COLLATE（如utf8mb4_general_ci），CONVERT 本身不携带排序规则
MySQL 8.0+ 中真正可用的 COLLATE 是什么
想让中文按拼音首字母稳定分组/排序，必须显式指定支持拼音比较的 COLLATE，而不是靠 CONVERT “蒙”：
-
utf8mb4_0900_as_cs（MySQL 8.0.1+）：大小写敏感 + 重音敏感，对简体中文首字母分组效果较稳（如“阿”“安”“八”“白”能正确分离），但注意它仍不是完整拼音排序，仅首字母可依赖 -
utf8mb4_unicode_ci不行：按 Unicode 码点排，“吖”（U+5422）和“八”（U+516B）差很远，“张”（U+5F20）甚至排在英文字母后面 - 不要混用：
CONVERT(name USING gbk) COLLATE utf8mb4_0900_as_cs是非法组合——CONVERT输出的是 GBK 字节流，而utf8mb4_0900_as_cs是 utf8mb4 的 collation，类型不匹配，MySQL 会静默转回默认 collation 或报错
分组统计拼音首字母的实操建议
如果你要的是“按姓氏拼音首字母分组并计数”，别硬套 CONVERT，直接用可落地的方式：
- 加一列
pinyin_first CHAR(1)，应用层或 ETL 时用标准拼音库（如 Python 的pypinyin、Java 的hanlp）计算并写入，再建索引：ALTER TABLE users ADD INDEX idx_pinyin_first (pinyin_first) - 临时查可用表达式（MySQL 8.0+）：
SELECT LEFT(name COLLATE utf8mb4_0900_as_cs, 1) AS first_letter, COUNT(*) FROM users GROUP BY first_letter ORDER BY first_letter—— 注意这里没用CONVERT，只靠COLLATE强制比较行为 - 避免在 GROUP BY 中用函数包裹字段：如
GROUP BY UPPER(LEFT(name, 1))会无法利用索引；同理GROUP BY CONVERT(name USING gbk)也无法走索引，且结果不可控 - 如果必须兼容老版本（MySQL 5.7），放弃服务端拼音排序，把首字母计算提到应用层——数据库只存原始字段，排序/分组逻辑由代码完成
最常被忽略的一点：CONVERT 是个“编码搬运工”，不是“拼音翻译器”。只要还在指望它返回“Z”代表“张”，就注定掉进字节 vs 语义的坑里。真正稳定的方案，永远是预计算 + 显式 collation，而不是在查询里反复折腾转换。
