CEIL和FLOOR跨数据库行为不一致：SQL Server用CEILING，SQLite需启用math扩展；负数向上取整向正无穷（CEIL(-2.3)=-2）；参数类型影响精度与隐式转换，金融计算需显式CAST；整数对齐优先用整数运算避免浮点误差。

CEIL 和 FLOOR 函数在不同数据库里名字一样但行为可能不一致

乍一看，CEIL和FLOOR似乎是SQL里的标准数学函数，但跨数据库时，细节上的差异足以让迁移脚本“翻车”。MySQL、PostgreSQL、Oracle这些主流数据库确实都支持，可一旦遇到SQL Server，直接写CEIL(x)就会收到一个冰冷的报错：Invalid column name 'CEIL'。因为它用的是CEILING。而SQLite的情况更特殊，它的ceil函数（注意是小写）属于数学扩展，如果没启用math extension，调用时会直接提示no such function: ceil。

这里有几个实用的应对策略：

• SQL Server：没有别的选择，必须把CEIL改成CEILING(x)。
• SQLite：如果环境限制无法加载扩展，有人会用CAST(x AS INTEGER) + CASE WHEN x % 1 > 0 THEN 1 ELSE 0 END这类组合来模拟向上取整，但切记，这种方法对负数处理不直观，不推荐在生产环境使用。
• 好消息是，对于NULL输入，各数据库的行为倒是一致：都返回NULL，这点无需额外操心。

负数的向上取整容易被误解：CEIL(-2.3) 是 -2，不是 -3

这是最容易踩坑的地方。很多人直觉上认为“向上”就是朝着数值更大的方向走，但数学定义恰恰相反：“向上取整”指的是向正无穷方向取最近的整数。所以，CEIL(-2.3)的结果是-2，而FLOOR(-2.3)才是-3。这个误解在涉及负值的业务场景里，比如财务退款（负金额表示支出）或异常值处理（负时间戳），可能导致严重的逻辑错误。

来看两个典型的错误场景：

• 计算退款金额时，输入-15.7元，本意是向上取整到-16元，但用了CEIL却得到-15元，导致少退了0.7元。
• 在将毫秒向上取整到秒时，对异常产生的负时间戳使用CEIL(x/1000)，结果完全不符合预期。

最可靠的验证方法是什么？在编写查询时，顺手加上一行测试：SELECT CEIL(-2.3), FLOOR(-2.3)。亲眼看到结果，心里才踏实。

CEIL/FLOOR 的参数类型影响精度，别让隐式转换坑了你

函数的行为不仅取决于数据库，还取决于你喂给它什么类型的数据。传入一个字符串'3.14'，MySQL会友好地帮你做隐式转换，但PostgreSQL会直接报错：function ceil(text) does not exist，要求你必须显式转换。更隐蔽的陷阱在于DECIMAL或NUMERIC这类高精度类型。在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，性能开销微乎其微，执行计划里通常也看不到额外成本。真正的性能瓶颈和逻辑错误，往往出现在复杂的嵌套表达式中。

举个例子，CEIL(x / y) * y这个模式常用于“将x向上对齐到y的倍数”。但如果x和y都是BIGINT这样的大整数，数据库可能会先将除法结果转为浮点数，再取整。这个过程中，浮点精度误差就可能悄然而至，比如处理接近BIGINT上限的值时。

如何规避这些问题？可以遵循以下实践：

• 整数对齐优先用整数运算：对于非负整数，公式((x + y - 1) / y) * y是更安全高效的选择，它完全避免了浮点数转换。
• 明确类型转换：当处理可能包含负数或必须使用浮点的场景时，主动控制类型：CEIL(CAST(x AS DECIMAL(20,6)) / y) * y。
• 慎用索引字段：在WHERE条件中使用FLOOR(timestamp_col)会导致无法使用索引。应改用范围查询：timestamp_col >= '2024-01-01' AND timestamp_col < '2024-01-02'。

最后，还有一个极易被忽略的“黑洞”：CEIL和FLOOR对NaN（非数字）和Infinity（无穷大）的处理完全没有标准。MySQL会返回NULL，PostgreSQL可能直接报错，而SQL Server的行为可能更不可预测。因此，在生产环境中，确保输入字段已经过滤掉这些非数值异常值，是必不可少的前置步骤。