FLOOR和CEILING在库存管理中必须明确选择：CEILING用于补货（如CEILING(35/12.0)=3箱），需防整数除法；FLOOR用于门槛判断（如FLOOR(499/500.0)=0），负数时行为反直觉，须谨慎处理。
FLOOR 和 CEILING 在库存管理中不是“可选”，而是“必须明确选哪个”——选错一个符号，补货量可能少算一整箱，或者多压两倍资金。
CEILING 用于“不够一单位也得算一单位”的补货场景
比如每箱装 12 件，当前缺货 35 件，那至少要订 CEILING(35 / 12.0) = 3 箱。注意除数必须带小数点（12.0），否则在 MySQL 或 SQL Server 中会触发整数除法，35 / 12 得 2，再 CEILING(2) 还是 2，直接少订一箱。
- 常见错误现象：
CEILING(quantity / 12)返回结果比预期少 1 —— 大概率是整数除法截断了小数部分 - 安全写法统一用
CEILING(quantity / 12.0)或CEILING(CAST(quantity AS DECIMAL) / 12) - Oracle 用户注意函数名是
CEIL()，不是CEILING()；SQLite 不支持CEILING()，得写-FLOOR(-quantity / 12.0)
FLOOR 用于“达标才生效”的库存门槛判断
例如“满 500 件享受批量折扣”，这时不能用 CEILING(total_qty / 500)，而要用 FLOOR(total_qty / 500.0) 得到可享优惠的完整档位数。假设总库存 499 件，FLOOR(499 / 500.0) = 0，不达标；500 件时才变成 1。
- 典型误用：
FLOOR(499 / 500)在 PostgreSQL 中直接报错：function floor(integer) does not exist —— 因为输入是整数，需显式转类型 - 跨库稳妥写法：
FLOOR(CAST(total_qty AS NUMERIC) / 500) - 别把
FLOOR当四舍五入用：FLOOR(amount + 0.5)在负数（如 -12.7）上会返回 -12，但正确四舍五入应为 -13
负数库存场景下 FLOOR/CEILING 行为完全反直觉
当系统允许负库存（如待出库未发货、调拨在途），FLOOR(-2.1) 返回 -3，CEILING(-2.9) 返回 -2 —— 这不是“去掉小数”或“加1”，而是严格朝负无穷（FLOOR）或零方向（CEILING）取整。
- 错误认知：“CEILING 就是进一”，结果
CEILING(-2.1)得 -2（正确），但CEILING(-2.9)也是 -2，不是 -3 - 真实影响：若用
CEILING(current_stock / -10.0)计算“还能支撑几个 10 件订单”，负数输入会让逻辑彻底反转 - 建议：负库存参与计算前，先用
CASE WHEN current_stock 分支处理，别硬套取整函数
性能与类型陷阱比函数逻辑本身更常导致线上故障
FLOOR(price_str) 看似能处理字符串字段，但在 PostgreSQL 中直接报错 function floor(text) does not exist；SQL Server 可能隐式转换成功，但遇到 'N/A' 就崩溃；索引也基本失效 —— 因为函数作用于字段后无法走索引。
- 字段是字符串？必须提前清洗并转换：
FLOOR(CAST(NULLIF(price_str, '') AS NUMERIC)) - WHERE 条件里慎用：
WHERE FLOOR(weight_kg) > 5基本等于放弃索引，改用范围查询WHERE weight_kg >= 5 AND weight_kg - 浮点误差风险：用
CEILING(1.1 / 0.1)理论该得 11，但二进制表示可能让结果略小于 11，CEILING后仍是 11 —— 概率低但存在，高精度场景（如金额分）建议先ROUND(x, 8)
真正难的不是记住 FLOOR 向下、CEILING 向上，而是每次写之前都得问一句：这个数可能是负的吗？它存的是字符串吗？我是在 WHERE 里用，还是 SELECT 里用？漏掉任意一项，生产环境就容易出货不准、账务对不上。
