sql的select支持直接写算术表达式进行四则运算，无需函数或子查询；可不查表，如select 5+3；注意null传播、除法精度、运算符优先级、跨库差异及聚合中运算顺序。

SELECT后面直接写算术表达式就能计算

SQL的SELECT语句本身支持基础四则运算（+、-、*、/），不需要额外函数或子查询。只要把表达式写在SELECT子句里，数据库就会当场计算并返回结果。

常见错误是误以为必须从表中取字段才能用SELECT，其实连表都不需要——比如SELECT 5 + 3;在大多数数据库里完全合法。

• 运算符优先级和数学一致：*和/先于+和-，可用括号调整
• 如果参与运算的字段为NULL，整个表达式结果也为NULL（不是报错）
• 除法结果类型取决于数据库：PostgreSQL中5/2得2（整数除），而5.0/2才得2.5；MySQL默认做浮点除，但显式声明类型更稳妥

对字段做运算时要注意数据类型和NULL传播

当你写SELECT price * 1.08 FROM products;给商品加税，实际执行依赖price字段的类型。如果price是INT，有些数据库（如SQL Server）会截断小数位，导致结果不精确。

• 用CAST(price AS DECIMAL(10,2)) * 1.08或price * 1.08（加小数点强制转浮点）避免整数截断
• COALESCE(price, 0) * 1.08可防止NULL让整行结果变NULL
• 别在WHERE里直接写price * 1.08 > 100做条件——虽然语法正确，但可能无法走索引；应优先考虑在应用层或视图里预计算

不同数据库对除零和负数取模处理不一致

执行SELECT 10 / 0;在PostgreSQL报错division by zero，SQLite返回NULL，MySQL默认返回NULL（但开启sql_mode='STRICT_TRANS_TABLES'时会报错）。负数取模更麻烦：-7 % 3在MySQL得-1，PostgreSQL得2。

• 生产环境务必用CASE WHEN denominator = 0 THEN NULL ELSE numerator / denominator END显式防御除零
• 取模运算尽量避免负数参与，或统一用ABS()包裹后再算，再根据业务逻辑补符号
• 跨数据库迁移SQL时，这类算术细节比语法更容易引发隐性bug

聚合函数里嵌套算术运算要小心执行顺序

像SELECT SUM(price * tax_rate) FROM orders;是先逐行算price * tax_rate再求和，而SELECT SUM(price) * tax_rate是先求和再乘——两者数学意义不同，结果也可能差很多。

• 确认业务含义：是“每笔订单按税率单独计税后汇总”，还是“总金额统一乘税率”？选错就全错了
• 聚合函数内部的表达式不能引用外部别名，例如SELECT price * 1.08 AS taxed, SUM(taxed)会报错——必须重写为SUM(price * 1.08)
• 涉及浮点运算时，SUM()累积误差可能比单次计算更大，金融场景建议用DECIMAL类型字段+固定精度运算

最易被忽略的是除法精度和NULL传播——它们不会报错，但会静默污染结果。上线前至少用NULL值和边界值（如0、负数、极大数）跑一遍测试数据。