直接SELECT salary*100+'%'会报错或结果异常，因数值与字符串不可直接相加；正确做法是先转字符串再拼接，且需按数据库选用TO_CHAR、CONCAT等函数，并处理小数位、NULL、负数等边界情况。
SELECT中直接乘100加百分号会报错吗
会，但不是语法错误，而是类型不匹配导致的隐式转换失败或结果异常。比如 SELECT salary * 100 + '%' FROM employees 在 PostgreSQL 或 SQL Server 中直接报错（不能把数字和字符串相加），MySQL 虽然可能“容忍”，但结果是 0 或科学计数法乱码——因为 + 触发了强制转数值，'%' 变成 0，最终算的是 salary * 100 + 0。
正确拼接百分号的写法（按数据库区分）
核心原则：先转字符串，再拼接。不同数据库函数名和语法细节差异大，不能混用：
- PostgreSQL / Redshift：用
TO_CHAR()控制小数位，再用||拼接SELECT TO_CHAR(0.8765, 'FM990.00') || '%' AS rate_pct FROM dual;→87.65% - MySQL：用
CONCAT()和ROUND()配合SELECT CONCAT(ROUND(0.8765 * 100, 2), '%') AS rate_pct; - SQL Server：用
CONCAT()或+（需显式转字符串）SELECT CONCAT(ROUND(0.8765 * 100, 2), '%');或CAST(ROUND(0.8765 * 100, 2) AS VARCHAR) + '%' - Oracle：
TO_CHAR()是首选，||拼接SELECT TO_CHAR(0.8765 * 100, 'FM990.00') || '%' FROM dual;
为什么不能只写 * 100 就完事
乘100只是数值放大，不解决三类实际问题：
- 小数位失控：原始值
0.1234567× 100 =12.34567，显示为12.34567%不符合业务习惯 - 空值（
NULL）传播：如果原字段为NULL，NULL * 100还是NULL，但拼接后变成NULL，前端可能渲染为空白，不如统一处理为'0.00%' - 负数和边界值：如
-0.001× 100 =-0.1，直接拼接成-0.1%易引发歧义，需结合ABS()或业务规则判断是否取绝对值
生产环境建议的健壮写法
别只图一行写完，加一层封装更可靠。例如在 PostgreSQL 中定义一个函数：
CREATE OR REPLACE FUNCTION pct_str(val NUMERIC, digits INT DEFAULT 2)
RETURNS TEXT AS $$
SELECT COALESCE(TO_CHAR(val * 100, 'FM990.' || REPEAT('0', digits)), '0.' || REPEAT('0', digits)) || '%';
$$ LANGUAGE sql;
调用：SELECT pct_str(0.1234567); → 12.35%，SELECT pct_str(NULL); → 0.00%。MySQL 用户可用存储函数或应用层统一格式化——数据库做计算，应用做展示，分工更清晰。
真正容易被忽略的是：百分比本质是「带单位的度量值」，不是纯数字。一旦后续要排序、求平均或参与计算，必须保留原始小数字段，pct_str 类函数只用于最终展示字段。
