select中运算存在null传播、整数除法截断、索引失效、别名不可用、优先级与类型不一致五大静默陷阱，需用coalesce、显式类型转换、重写条件、生成列及括号等手段规避。

SELECT 中直接写 +、-、*、/ 能算，但结果常和预期不符——不是语法错，而是 NULL、类型隐式转换、除法截断、索引失效这些“静默陷阱”在捣鬼。

NULL 参与运算导致整行消失

只要任一字段为 NULL，比如 price + discount 中 discount 是 NULL，结果就是 NULL，不是 0，也不是原值，整行数据在结果里“变透明”了。

• 用 COALESCE(discount, 0) 把空值转为 0 —— 这是最通用写法，MySQL/PostgreSQL/SQL Server 都支持
• MySQL 可用 IFNULL(discount, 0)；SQL Server 推荐 ISNULL(discount, 0)
• 别写 discount + 0 试图“唤醒” NULL —— 无效，NULL + 0 还是 NULL

整数除法跨库结果不一致

写 revenue / cost 看似简单，但 5 / 2 在 PostgreSQL 和 SQL Server 返回 2，MySQL 可能返回 2.5，全看底层类型推导规则，跨库迁移时极易出错。

• 要小数结果，至少让一个操作数带小数点：revenue * 1.0 / cost 或 CAST(revenue AS DECIMAL(10,2)) / cost
• 用 NULLIF(cost, 0) 防除零：revenue / NULLIF(cost, 0)，除零时返回 NULL 而非报错
• 若需统一兜底（比如除零时显示 0），再套一层：COALESCE(revenue / NULLIF(cost, 0), 0)

WHERE 中对字段运算会让索引失效

WHERE price * 1.1 > 100 看起来合理，但优化器无法用 price 上的索引加速——因为 price * 1.1 是计算值，不是原始索引键。

• 重写为等价范围条件：WHERE price > 100 / 1.1（前提是业务允许该精度）
• 高频计算场景，建生成列并索引：ALTER TABLE products ADD COLUMN price_with_tax AS (price * 1.1) STORED（MySQL/PostgreSQL）或 PERSISTED（SQL Server）
• 别在 WHERE 里用函数包裹字段，如 WHERE CAST(price AS FLOAT) > 100，同样破坏索引

别名不能在 WHERE 或 GROUP BY 里直接用

写 SELECT quantity * unit_price AS total FROM orders ORDER BY total DESC 没问题，但 WHERE total > 100 会报错：列名 total 不存在。

• WHERE 执行早于 SELECT，所以别名还没诞生；必须重复写表达式：WHERE quantity * unit_price > 100
• 真想复用，得用子查询或 CTE：WITH calc AS (SELECT *, quantity * unit_price AS total FROM orders) SELECT * FROM calc WHERE total > 100
• 括号优先级常被忽略：base + discount * rate ≠ (base + discount) * rate，涉及混合运算务必加括号

最易被跳过的其实是类型一致性：金额类计算前，所有参与字段最好先 CAST 到统一精度类型再运算。否则不同数据库推导规则不同，可能精度丢失或溢出。