UPDATE语句中直接写数学表达式是安全的，但需注意NULL值处理、类型兼容性、隐式转换风险及数据质量导致的函数执行失败。
UPDATE 语句里直接写数学表达式是安全的
SQL 的 UPDATE 支持在 SET 子句中直接使用算术运算和内置函数，不需要额外子查询或临时表。只要字段类型兼容，数据库会逐行计算并更新——这是最常用也最高效的批量逻辑更新方式。
常见错误现象：UPDATE products SET price = price * 1.1 WHERE category = 'electronics' 执行后部分价格变成 NULL，往往是因为 price 字段允许 NULL，而 NULL * 1.1 仍为 NULL。
- 用
COALESCE(price, 0)或IS NOT NULL显式过滤空值 - 整数字段做除法时注意截断（如 MySQL 中
5 / 2 = 2），改用5.0 / 2或CAST(5 AS DECIMAL) - PostgreSQL 对类型敏感，
price + '10'会报错；MySQL 可能隐式转成数字，但行为不可靠
嵌套函数组合要小心执行顺序和空值传播
像 ROUND(LOG(price), 2) 这类组合，失败点常不在语法，而在数据质量：如果某行 price ，<code>LOG() 在多数数据库中返回 NULL 或报错（如 PostgreSQL 报 invalid argument for logarithm）。
使用场景：给老用户积分按活跃度加权更新，比如 score = GREATEST(100, LEAST(500, base_score + FLOOR(LOG2(days_active + 1)) * 20))。
-
GREATEST/LEAST可替代多层CASE WHEN实现边界控制 -
COALESCE必须包在最外层或关键函数内，例如LOG(COALESCE(price, 1))，而不是COALESCE(LOG(price), 0)（后者 LOG 已报错） - SQLite 不支持
LOG2，得用LOG(price) / LOG(2)；Oracle 需写LOG(2, price)
WHERE 条件里混用函数会导致索引失效
写 WHERE UPPER(name) = 'JOHN' 看似方便，但几乎所有数据库都无法走 name 字段上的普通索引——全表函数计算开销大，且结果不可预测。
性能影响明显：百万级表上该条件可能从几毫秒变几秒。
- 优先用大小写不敏感的校对规则（如 MySQL 的
utf8mb4_0900_as_cs）或生成列+索引 - 必须用函数时，考虑建函数索引（PostgreSQL/Oracle 支持
CREATE INDEX ON t ((UPPER(name)))；MySQL 8.0+ 支持函数索引但仅限于虚拟列） -
WHERE date_created > NOW() - INTERVAL '7 days'比WHERE EXTRACT(DAY FROM AGE(NOW(), date_created)) 更易命中索引（PostgreSQL）
批量更新涉及多表时，JOIN 写法因数据库而异
想用订单表的 total_amount 更新用户表的 lifetime_spend，不同数据库语法差异大，不能无脑套用。
错误示例：UPDATE users u JOIN orders o ON u.id = o.user_id SET u.lifetime_spend = u.lifetime_spend + o.total_amount —— 在 PostgreSQL 和 SQL Server 上语法错误。
- MySQL 支持
UPDATE ... JOIN，但只允许一个目标表 - PostgreSQL 用
FROM子句：UPDATE users SET lifetime_spend = lifetime_spend + o.total_amount FROM orders o WHERE users.id = o.user_id - SQL Server 用
UPDATE u SET ... FROM users u JOIN orders o ON ... - 所有方案都要加
WHERE限制匹配行数，否则没关联上的用户会被设为NULL（除非显式COALESCE）
真正麻烦的是跨库或带聚合的更新，比如“把每个用户的平均订单额更新到 profile 表”，这时单条 SQL 很难兼顾可读性、原子性和性能，得拆成 CTE + UPDATE 或应用层分批处理。函数和运算本身不难，难的是让它们在真实数据分布和引擎特性下稳定生效。
