ceiling函数在运费计算中需先缩放再取整，如每0.5kg计费则用ceiling(weight/0.5)0.5，确保不足单位也按一档计费；首重单独处理，续重部分用ceiling(greatest(0,weight-首重)/单位)单位。
CEILING 函数在运费计算中到底怎么用？
物流运费常按重量或体积分段计价，比如“每0.5kg收8元”，这时不能简单四舍五入——0.1kg也要算作0.5kg，必须向上取整。SQL 的 CEILING 函数正好干这事，但它默认对整数倍取整，直接用 CEILING(weight) 会错：它把 0.6kg 变成 1kg，而不是 1 × 0.5kg = 0.5kg 的下一个单位（即 1.0kg）。正确做法是先缩放再取整：把原始值除以单位（如 0.5），CEILING 后再乘回去。
- 错误写法：
CEILING(0.6)→ 1（本应按 0.5kg 单位向上取到 1.0） - 正确写法：
CEILING(0.6 / 0.5) * 0.5→CEILING(1.2) * 0.5→ 2 * 0.5 = 1.0 - 注意：除数不能为 0，实际业务中要加
WHERE unit_weight > 0或用CASE WHEN防御
FLOOR 和 CEILING 在运费分段场景下谁该用？
多数运费规则是“向上靠档”，比如首重1kg内12元，续重每0.5kg加5元——续重部分必须向上取整，不能向下。这时候 FLOOR 只适合极少数场景，例如“满10kg减2元”这种门槛判断（FLOOR(total_weight / 10) 得到可享受优惠的次数），但绝不能用于计费基数。误用 FLOOR 会导致少收钱，比如 1.1kg 续重按 0.5kg 单位算，FLOOR(1.1 / 0.5) = FLOOR(2.2) = 2 → 2 × 0.5 = 1.0kg，漏掉剩余 0.1kg 应计的 1 档费用。
- 向上计费（主流）→ 用
CEILING缩放法 - 门槛达标判断（如满减、包邮）→ 可用
FLOOR，但要确认是否包含边界（FLOOR(9.99 / 10) = 0，不达标） - 混合场景（首重+续重）：首重单独判断，续重部分用
CEILING(GREATEST(0, weight - 1) / 0.5) * 0.5
不同数据库对 CEILING 的行为差异有哪些？
MySQL、PostgreSQL、SQL Server 的 CEILING 行为一致：返回>=输入值的最小整数。但 SQLite 没有 CEILING，得用 -FLOOR(-x) 替代；而 Oracle 的 CEIL 是等价函数，拼写不同。另外，浮点精度可能引发意外：比如 CEILING(1.1 / 0.1) 理论上是 CEILING(11.0) = 11，但二进制浮点误差可能导致结果是 10.999…，CEILING 后仍得 11 —— 大概率没问题，但若单位是 0.01 元这类小数，建议先 ROUND(x, 6) 再 CEILING 避免边缘误差。
- SQLite 替代写法：
-FLOOR(-weight / 0.5) - Oracle 用
CEIL，不是CEILING（否则报错） - 避免直接除小数：用
CEILING(weight * 100 / 50.0)（转为整数运算）更稳
真实 SQL 示例：计算含首重和续重的总运费
假设首重1kg收费15元，续重每0.3kg加4元，重量字段为 parcel_weight（单位kg），以下语句可直接运行：
SELECT
id,
parcel_weight,
15 +
CASE
WHEN parcel_weight <p>这里关键点是：续重部分先减首重，再按 0.3kg 单位向上取整，最后乘单价。如果 <code>parcel_weight</code> 为 NULL，整个表达式结果为 NULL，生产环境建议补 <code>COALESCE(parcel_weight, 0)</code> 或过滤。</p><p>真正容易出问题的不是函数本身，而是单位换算时漏乘/漏除、边界值（如刚好1kg）没覆盖、以及不同数据库函数名不兼容——这些地方一错，运费就少算或多算，而且很难被测试用例全部捕获。</p>
