SQL中拼接%符号会将数值转为字符串，导致无法参与数值计算；正确做法是计算阶段返回纯数值（如ROUND(score/full_score*100,2)），展示阶段再格式化加%。
SQL中直接拼接%符号导致结果变成字符串
很多用户发现写 SELECT score * 100 || '%' FROM students 后，原本想得到“85.5%”这种显示效果，结果却让后续计算失效——因为 ||（或 CONCAT）强制把数值转成字符串。数据库不再认它是数字，没法再求平均、排序或参与 WHERE 数值比较。
- PostgreSQL/Oracle 用
||，MySQL 8.0+ 也支持，但拼接后类型为text或varchar - SQL Server 用
+拼接，同样触发隐式转换，且空值会让整行变NULL - 真正需要百分比展示时，应区分「计算用数值」和「展示用字符串」两个阶段
正确做法：先算数值比例，再格式化为带%的字符串
百分比本质是「原始值 ÷ 基准值 × 100」，不是简单乘100。比如统计及格率，分母得是总人数，不是固定100；又比如每个学生的得分率，分母该是满分值。
- 计算阶段用
ROUND(score / full_score * 100, 2)得到数值型百分比（如85.50） - 展示阶段再转字符串：
CONCAT(ROUND(score / full_score * 100, 2), '%')（MySQL）、ROUND(...)::TEXT || '%'（PostgreSQL） - 注意除零风险：加
CASE WHEN full_score = 0 THEN NULL ELSE ... END避免报错
不同数据库的百分比格式化函数差异
有些数据库提供内置格式化能力，能自动补小数位、对齐、甚至本地化符号，比手动拼接更稳。
- PostgreSQL：用
TO_CHAR(percentage, 'FM990.00%')，其中FM去前导空格，990.00表示最多三位整数+两位小数 - SQL Server：用
FORMAT(percentage, 'N2', 'en-US') + '%'，但注意FORMAT性能较差，大数据量慎用 - MySQL：无原生百分比格式化，老版本只能靠
CONCAT(ROUND(...), '%')；8.0.17+ 可用FORMAT(score * 100, 2)先格式化数字再拼
WHERE 或 ORDER BY 中千万别用拼接后的字符串做数值判断
这是最常踩的坑：有人写 WHERE CONCAT(ROUND(rate*100,1), '%') > '90%'，指望它筛选大于90%的记录——实际是字符串比较，'100%'
- 过滤或排序必须基于原始数值列，例如
WHERE rate >= 0.9或ORDER BY rate DESC - 如果只有拼接后的字段（比如视图里只暴露了
rate_str），得用CAST(REPLACE(rate_str, '%', '') AS DECIMAL(5,2))提取数字，但性能差且易出错 - 临时表或 CTE 中提前算好数值型百分比列，比运行时反复解析字符串可靠得多
实际业务里，百分比要么是中间计算指标（保持数值型），要么是最终报表字段（单独格式化）。混用两者，八成会掉进类型陷阱。
