MySQL原生不支持汉字转拼音，CONVERT()和COLLATE仅影响排序比较，无法提取拼音首字母；可行方案包括外部预处理、UDF（5.7+默认禁用）、存储函数+映射表（性能差、维护难）或MySQL 8.0+ JSON硬编码映射（轻量但难扩展）。
MySQL原生不支持汉字转拼音，CONVERT() 或 COLLATE 只能影响排序和比较，无法提取拼音首字母。真要实现“快速提取”，必须绕过纯SQL方案——要么用外部程序预处理，要么在MySQL中用自定义函数（UDF）或存储函数配合字符映射表。但要注意：后者性能差、维护难，且5.7+默认禁用UDF加载。
为什么不能只靠 COLLATE 或内置函数？
常见误区是尝试用 CONVERT(col USING gbk) 或 col COLLATE gbk_chinese_ci 来“触发”拼音逻辑——这完全无效。MySQL的字符集校对规则只决定排序顺序（比如把“张”和“章”视为等价），不提供拼音生成能力。执行 SELECT CONVERT('李' USING gbk) 返回的仍是字节数据，不是拼音字符串。
用存储函数 + 静态映射表是最可行的方案
前提是你能接受有限覆盖（常用汉字约3500个）和单字处理（不支持多音字上下文判断）。核心思路是建一张 hanzi_pinyin 表，含 char（单字符）、pinyin_first（首字母大写），然后封装成函数：
DELIMITER $$ CREATE FUNCTION get_pinyin_first(c CHAR(1)) RETURNS CHAR(1) CHARSET utf8mb4 READS SQL DATA DETERMINISTIC BEGIN DECLARE result CHAR(1) DEFAULT ''; SELECT pinyin_first INTO result FROM hanzi_pinyin WHERE `char` = c LIMIT 1; RETURN IFNULL(result, ''); END$$ DELIMITER ;
-
READS SQL DATA和DETERMINISTIC必须显式声明，否则创建失败 - 表里需预先填充汉字及对应首字母，例如
INSERT INTO hanzi_pinyin VALUES ('王', 'W'), ('李', 'L') - 函数对非汉字（如英文、数字）返回空字符串，需自行加
IF c REGEXP '^[\u4e00-\u9fa5]$'判断（MySQL 8.0+才支持Unicode正则） - 每调用一次
get_pinyin_first()就查一次表，批量处理时性能明显下降
MySQL 8.0+ 可用 JSON 表达式做轻量级映射（无表依赖）
如果只处理几百个高频字，可把映射关系硬编码进JSON字符串，避免建表和IO开销：
CREATE FUNCTION get_pinyin_first_lite(c CHAR(1))
RETURNS CHAR(1) CHARSET utf8mb4
DETERMINISTIC
BEGIN
SET @map = '{"王":"W","李":"L","张":"Z","刘":"L","陈":"C","杨":"Y","赵":"Z","黄":"H","周":"Z","吴":"W"}';
RETURN COALESCE(JSON_UNQUOTE(JSON_EXTRACT(@map, CONCAT('$.', c))), '');
END;
- 适合启动快、改动少的场景；超过1000字时JSON字符串会臃肿，且不易更新
-
JSON_EXTRACT()在8.0.1+稳定，旧版本会报错 - 注意双引号和反斜杠转义——汉字本身不用转义，但JSON字符串里的双引号必须用
" - 该函数无法处理空格、标点、emoji，输入前建议用
TRIM()和LENGTH(c) = 1过滤
真正需要高并发、全汉字覆盖、多音字识别的场景，别在MySQL里硬扛。把拼音逻辑下沉到应用层（Python用 pypinyin，Java用 hutool），或者用MySQL Router前置处理。数据库里的函数容易变成技术债——尤其当DBA禁用自定义函数或升级后权限模型变更时，连 SHOW FUNCTION STATUS 都可能看不到它在哪定义的。
