<p>直接CONCAT(col * 100, '%')会导致小数位不可控，因乘法保留原始精度且CONCAT不截断；应先用ROUND控制位数再拼接，并注意各数据库类型转换差异及NULL处理。</p>
MySQL里用CONCAT拼百分号前为什么小数点后位数乱了
直接CONCAT(col * 100, '%')会导致小数位不可控，比如0.12345变成12.345%，而业务常要12.35%或12%。根本原因是*运算保留原始精度，CONCAT不做截断或四舍五入。
实操建议：
- 先用
ROUND(col * 100, 2)控制小数位数，再拼接，例如：CONCAT(ROUND(0.12345 * 100, 2), '%')→12.35% - 如果只要整数百分比，用
ROUND(col * 100, 0)，避免出现12.0%这种带多余小数点的格式 - 注意
ROUND()在MySQL中对.5的处理是“四舍六入五成双”，如需严格四舍五入，可考虑ROUND(col * 100 + 0.0001, 2)微调（仅限小数位少的场景）
PostgreSQL中CONCAT不认ROUND返回的numeric类型？
PostgreSQL的CONCAT要求所有参数为text或可隐式转为text，而ROUND(0.12345 * 100, 2)返回的是numeric，直接拼接会报错：function concat(numeric, unknown) does not exist。
实操建议：
- 显式转类型：
CONCAT(ROUND(0.12345 * 100, 2)::TEXT, '%') - 或用
TO_CHAR更稳妥，它天然支持格式化和类型转换：TO_CHAR(0.12345 * 100, 'FM990.00') || '%'（FM去前导空格，990.00表示最多两位小数） -
||比CONCAT在PG里更常用，且对类型宽容度略高，但依然推荐显式转TEXT以防意外
SQL Server里CONCAT自动转类型，但乘100后精度溢出怎么办
SQL Server中CONCAT确实会自动把数值转varchar，但DECIMAL(5,4)列乘100后可能变成DECIMAL(7,2)，若原值是0.9999，乘完是99.99没问题；但如果是DECIMAL(18,10)，乘100后小数位减少、整数位膨胀，可能触发隐式转换截断或报错Arithmetic overflow error。
实操建议：
- 用
CAST或CONVERT提前限定结果范围，例如：CONCAT(CAST(ROUND(col * 100, 2) AS DECIMAL(5,2)), '%') - 避免直接
col * 100，尤其当col是高精度DECIMAL时，先CAST(col AS FLOAT)再算（牺牲精度换安全，适合报表类场景） - 测试边界值：用
0.9999999999这类最大可能值跑一遍，看是否溢出
百分比字符串排序失效——因为CONCAT后变文本了
一旦用CONCAT(..., '%')生成字符串，就再也无法按数值大小排序。比如'100%'会排在'20%'前面（字典序），而不是后面（数值序）。
实操建议：
- 显示和排序必须分离：SELECT里用
CONCAT做展示字段，ORDER BY仍用原始数值或col * 100计算字段 - 如果必须单字段兼顾显示与排序，建计算列（MySQL 5.7+/8.0，SQL Server，PG 12+）：
ALTER TABLE t ADD percent_display TEXT AS (CONCAT(ROUND(val * 100, 2), '%')) STORED，但排序仍得靠另一列 - 别试图用
CAST(REPLACE(percent_col, '%', '') AS DECIMAL)实时转换再排序——性能差，且空值、异常字符会崩
百分比转换看着简单，真正卡住人的往往是小数位控制逻辑、数据库类型隐式转换规则、以及显示和计算职责混在一起。最常被跳过的一步：没验证NULL值参与运算时的行为——NULL * 100还是NULL，但CONCAT(NULL, '%')在多数数据库里变成NULL，不是'%'。
