ceil和floor跨数据库行为不一致：sql server用ceiling，sqlite需启用math扩展；负数向上取整向正无穷（ceil(-2.3)=-2）；参数类型影响精度与隐式转换，金融计算需显式cast；整数对齐优先用整数运算避免浮点误差。
CEIL 和 FLOOR 函数在不同数据库里名字一样但行为可能不一致
MySQL、PostgreSQL、Oracle 都支持 CEIL 和 FLOOR，但 SQL Server 用的是 CEILING（不是 CEIL），而 SQLite 只有 ceil（小写）且是扩展函数，需启用 math extension 才能用。如果跨库迁移 SQL，直接写 CEIL(x) 在 SQL Server 会报错：Invalid column name 'CEIL'。
实操建议：
- SQL Server 必须改用
CEILING(x) - SQLite 若未加载 math 扩展，
ceil(x)会提示no such function: ceil，可临时用CAST(x AS INTEGER)+ 条件判断模拟，但不推荐用于负数 - PostgreSQL 对
CEIL输入NULL返回NULL，这点各库一致，无需额外处理
负数的向上取整容易被误解：CEIL(-2.3) 是 -2，不是 -3
“向上取整”是指向正无穷方向取最近整数，不是“往更大的数走”。所以 CEIL(-2.3) 结果是 -2，FLOOR(-2.3) 才是 -3。很多人凭直觉以为“向上=数值变大”，结果在处理温度、财务损益等含负值场景时出错。
常见错误现象：
- 用
CEIL计算折扣后价格，输入 -15.7（表示退款 15.7 元），得到 -15，导致少退 0.7 元 - 日志分析中对耗时毫秒做
CEIL(x/1000)求秒级向上取整，但 x 为负（异常时间戳）时逻辑崩坏
验证方法：在查询里加测试数据，比如 SELECT CEIL(-2.3), FLOOR(-2.3)，亲眼确认结果再上线。
CEIL/FLOOR 的参数类型影响精度，别让隐式转换坑了你
传入字符串如 '3.14' 时，MySQL 会自动转成浮点数再计算；但 PostgreSQL 要求显式转换，否则报错：function ceil(text) does not exist。更隐蔽的是 DECIMAL 类型：在 MySQL 中 CEIL(DECIMAL(10,2)) 返回 DECIMAL，而 PostgreSQL 返回 NUMERIC，精度位数可能变化。
使用场景提醒：
- 金融计算中，若字段是
DECIMAL(15,4)，用FLOOR(amount * 100) / 100截断小数，比直接FLOOR(amount)更可控 - 避免写
CEIL('2.9')—— 字符串强转浮点可能丢失精度，尤其超长数字如'123456789012345.678' - PostgreSQL 中必须写
CEIL(col::numeric)或CEIL(CAST(col AS numeric))，不能依赖隐式转换
性能上 CEIL/FLOOR 几乎无开销，但嵌套表达式要注意计算顺序
单个 CEIL 或 FLOOR 是纯数学运算，执行计划里看不到额外 cost。问题常出在组合使用时，比如 CEIL(x / y) * y 本意是“向上对齐到 y 的倍数”，但如果 x 和 y 是 BIGINT，除法先转浮点再取整，可能因浮点精度丢数（如 9223372036854775807 / 1000 → 浮点误差）。
实操建议：
- 整数对齐优先用整数运算：
((x + y - 1) / y) * y（适用于 x ≥ 0 且 y > 0） - 需要兼容负数或浮点输入时，明确 cast 类型：
CEIL(CAST(x AS DECIMAL(20,6)) / y) * y - WHERE 条件中慎用
FLOOR(timestamp_col)，它无法走索引；应改用范围查询：timestamp_col >= '2024-01-01' AND timestamp_col
最易被忽略的一点：CEIL 和 FLOOR 对 NaN 和 Infinity 的行为未标准化——MySQL 返回 NULL，PostgreSQL 报错，SQL Server 直接崩溃。生产环境务必确保输入字段已过滤掉非数值异常值。
