直接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 类函数只用于最终展示字段。