这个问题其实是MySQL里ROUND函数对不同数值类型的舍入规则差异，加上字符串转数值的类型转换逻辑导致的，我来给你拆解清楚：

1. MySQL的ROUND函数有两套舍入规则 #

MySQL的ROUND函数行为会根据参数的数值类型而不同：

• 针对DECIMAL等精确数值类型：使用传统的「四舍五入」规则——当数值是整数中间值（比如0.5、26.5）时，会向上舍入到更大的整数。
• 针对DOUBLE/FLOAT等近似数值类型：使用「银行家舍入法」（四舍六入五成双）——当数值正好是两个整数的中间值时，会舍入到最近的偶数。比如：
  • 0.5 → 0（最近的偶数）
  • 1.5 → 2（最近的偶数）
  • 26.5 → 26（最近的偶数）

2. 字符串转数值的类型转换逻辑 #

这是问题的关键：

• 当你直接写0.5这种数值字面量时，MySQL会将其解析为DECIMAL类型（精确数值），所以ROUND(0.5)遵循四舍五入，返回1。
• 当你传入'0.5'这种字符串时，MySQL会自动将其转换为DOUBLE类型（近似数值），此时ROUND触发银行家舍入法，返回0。
• 同理，'26.5' + 0.00的操作会先把字符串转成DOUBLE再做加法，结果还是DOUBLE类型，所以ROUND('26.5' + 0.00)返回26。

3. 为什么1.5的字符串版本看起来正常？ #

因为按照银行家舍入法，1.5的中间值舍入到最近的偶数就是2，这和传统四舍五入的结果一致，所以你会觉得符合预期——但本质上它用的还是银行家舍入规则，只是结果刚好和四舍五入相同而已。

4. Oracle的行为差异 #

Oracle的ROUND函数不管参数是字符串还是数值，统一使用传统四舍五入规则，而且字符串会被转换为精确数值类型处理，所以所有场景下ROUND('0.5')和ROUND(0.5)都会返回1，和你预期的一致。

验证方法 #

如果你想让字符串类型的数值也遵循四舍五入，可以强制将其转换为DECIMAL类型：

SELECT ROUND(CAST('0.5' AS DECIMAL(10,1))); -- 返回1
SELECT ROUND(CAST('26.5' AS DECIMAL(10,1))); -- 返回27

内容的提问来源于stack exchange，提问作者David Abragimov