MySQL无法直接创建纯SQL中文大写转换函数，因原生不支持循环、递归及复杂字符串处理；可行方案为：使用DELIMITER+BEGIN...END存储过程式函数（需配置权限）或移至应用层处理。
MySQL中无法直接创建纯SQL的中文大写转换函数
MySQL原生不支持在CREATE FUNCTION中使用循环、递归或复杂字符串拼接逻辑（尤其5.7及更早版本），且内置函数缺乏Unicode汉字处理能力。你写出来的DETERMINISTIC函数大概率会在调用时报ERROR 1418（未声明SQL SECURITY）或ERROR 1303（函数体内不能含语句块），更别说正确处理“零”的省略、“拾”“佰”“仟”的位权跳转了。
真正能跑通的方案只有两个：用DELIMITER + BEGIN...END写存储过程式函数（需开启log_bin_trust_function_creators=1），或把转换逻辑前置到应用层。
用存储过程语法写可运行的num_to_chinese函数（MySQL 5.7+）
这个函数能处理0～99999999之间的整数，核心是拆位+查表+状态机式“零”压缩：
DELIMITER $$ CREATE FUNCTION num_to_chinese(n BIGINT UNSIGNED) RETURNS VARCHAR(100) CHARSET utf8mb4 READS SQL DATA DETERMINISTIC SQL SECURITY DEFINER BEGIN DECLARE result VARCHAR(100) DEFAULT ''; DECLARE digits VARCHAR(20) DEFAULT '零壹贰叁肆伍陆柒捌玖'; DECLARE units VARCHAR(20) DEFAULT '元角分'; DECLARE i INT DEFAULT 0; DECLARE digit CHAR(2); DECLARE unit CHAR(2); <p>IF n = 0 THEN RETURN '零元'; END IF;</p><p>-- 简化版：只做整数部分万以内转换（避免过度复杂） SET @s = CAST(n AS CHAR); SET @len = LENGTH(@s); SET @pos = 1; WHILE @pos <= @len DO SET digit = SUBSTRING(digits, (SUBSTRING(@s, @pos, 1) + 1) * 2 - 1, 2); SET unit = CASE @len - @pos + 1 WHEN 4 THEN '仟' WHEN 3 THEN '佰' WHEN 2 THEN '拾' ELSE '' END; IF digit != '零' OR @pos = @len OR SUBSTRING(@s, @pos + 1, 1) != '0' THEN SET result = CONCAT(result, digit, unit); ELSEIF RIGHT(result, 2) != '零' THEN SET result = CONCAT(result, '零'); END IF; SET @pos = @pos + 1; END WHILE;</p><p>RETURN CONCAT(result, '元'); END$$ DELIMITER ;
注意几个硬坑：
- 必须用
CHARSET utf8mb4，否则中文返回乱码或截断 -
READS SQL DATA和SQL SECURITY DEFINER缺一不可，否则权限报错 - MySQL字符串索引从1开始，且
SUBSTRING(str, pos, len)里pos超界会返回空，不报错但逻辑崩坏 - “零”的连写抑制（如1001 → “壹仟零壹元”而非“壹仟零零零壹元”）需额外状态变量，上面示例仅作示意，生产环境建议砍掉复杂规则，交给Java/Python做
更靠谱的做法：在应用代码里做转换，MySQL只存数字
把数字当字符串传给后端，用成熟库处理，比如：
- Python用
cn2an：cn2an.num2cn(12345, big=True, alt=False)→'壹万贰仟叁佰肆拾伍' - Java用
hutool：ChineseNumberUtil.toChineseNumber(12345) - Node.js用
chinese-numerals：toChinese(12345, { format: 'financial' })
这样做的好处是：
- 避免MySQL函数调试困难（无
print、无断点、错误信息极简） - 财务场景常需扩展（如加“整”字、处理小数点后两位、区分“元角分”），SQL函数维护成本爆炸
- 字符集、排序规则、主从同步等边界问题全绕开
如果非要在MySQL里用，优先考虑视图+预计算表
对固定范围数字（比如订单金额只在1～10000之间），建一张映射表比写函数更稳：
CREATE TABLE num_chinese_map ( num INT PRIMARY KEY, chinese VARCHAR(50) CHARSET utf8mb4 NOT NULL ); -- 批量插入：INSERT INTO num_chinese_map VALUES (0,'零'),(1,'壹'),...;
查询时直接JOIN：
SELECT t.order_id, m.chinese AS amount_cn FROM orders t JOIN num_chinese_map m ON t.amount = m.num;
这种方案没有函数编译风险，执行计划清晰，还能加INDEX加速。唯一代价是初始化工作量——但比调试一个永远少一个“零”的SQL函数省心多了。
真正难的不是写出能跑的SQL，而是让“壹万零捌元”里的“零”既不多也不少。这事交给专业文本处理库，MySQL就老老实实存数字。
