SQL算术运算直接用+、-、*、/，无需函数；注意除法类型差异、NULL传播、除零处理（CASE或NULLIF/COALESCE）、日期运算跨库不兼容，以及计算列导致索引失效问题。
SQL里加减乘除直接写在SELECT里就行
算术运算符（+、-、*、/）在SELECT子句中可直接用于数值列，不需要额外函数包装。比如想把价格翻倍再减去5元，写成price * 2 - 5即可生效。
常见错误是误以为要调用类似ADD()或MULTIPLY()这类不存在的函数——SQL标准里没有这种函数，全是原生运算符。
- 除法
/结果类型取决于数据库：PostgreSQL和SQL Server会保留小数，MySQL默认整除（除非至少一个操作数是浮点数，如price / 2.0） - 遇到
NULL参与运算时，整条表达式结果直接为NULL，不是报错 - 字段别名必须用
AS显式声明，否则多数数据库会报错或生成无意义列名（如price * 1.1 AS new_price）
处理除零错误：用CASE或COALESCE兜底
SELECT price / discount_rate看着简单，但只要discount_rate出现0值，MySQL会返回NULL，PostgreSQL直接报错division by zero，SQL Server也抛异常。
最稳妥写法是提前拦截：
SELECT CASE WHEN discount_rate = 0 THEN NULL ELSE price / discount_rate END AS effective_ratio, COALESCE(NULLIF(discount_rate, 0), 1) AS safe_rate
注意：NULLIF(a, b)在a等于b时返回NULL，否则返回a；COALESCE取第一个非NULL值——这两个组合能避免除零，但逻辑要按业务需求调整（比如是否该用1代替0？还是该标为NULL？）
日期和数字混算：小心隐式转换陷阱
某些数据库（如MySQL）允许date_column + 7表示“加7天”，但这不是标准SQL行为。PostgreSQL要求明确用date_column + INTERVAL '7 days'，SQL Server要用DATEADD(day, 7, date_column)。
数值列和日期列硬拼会出问题：
- 写
order_date + amount在MySQL里可能意外转成Unix时间戳加整数，结果完全不可读 - SQL Server中
datetime + int会被解释为“加多少天”，但datetime + float就报错 - 跨数据库迁移时，这种写法几乎必然失效，建议统一用标准日期函数
性能影响：计算列不走索引，除非建函数索引
WHERE price * 1.1 > 100这种条件无法利用price字段上的普通索引——数据库得先把每行price算一遍再比较，等价于全表扫描。
优化办法只有两个：
- 改写为
WHERE price > 100 / 1.1，让运算移到常量侧（前提是运算可逆且语义不变） - 在支持函数索引的数据库（PostgreSQL、MySQL 8.0+、SQL Server）上显式创建：
CREATE INDEX idx_price_tax ON orders ((price * 1.1))
别指望查询优化器自动帮你倒推公式——它不会把price * 1.1 > 100重写成price > 90.909...，这事得人来判断和调整。
