floor向下取整（返回≤x的最大整数），ceil向上取整（返回≥x的最小整数）；二者负数行为易错：floor(-2.7)=-3，ceil(-2.7)=-2；数据库函数名不统一，postgresql/mysql用ceil，sql server只认ceiling。
SQL中FLOOR和CEIL函数的基本行为
FLOOR 总是向下取整，即返回不大于输入值的最大整数；CEIL（或 CEILING，取决于数据库）总是向上取整，即返回不小于输入值的最小整数。它们都作用于数值型表达式，返回相同类型的整数（通常是 DECIMAL 或 INT，具体看输入类型和数据库实现）。
注意：不同数据库对函数名支持略有差异——PostgreSQL、MySQL、Snowflake 用 CEIL；SQL Server 只认 CEILING；Oracle 两者都支持。别写成 CEILING() 却在 MySQL 里执行，会报错 FUNCTION xxx.CEILING does not exist。
常见错误：对负数取整结果不符合直觉
很多人以为“向下”就是“往更小数字方向”，但数学定义中“向下取整”是朝负无穷方向，所以 FLOOR(-2.7) 结果是 -3，不是 -2；同理 CEIL(-2.7) 是 -2，不是 -3。这在计算页码、分桶编号或偏移量时容易出错。
- 若想对负数也按“截断小数部分”处理（即向零取整），不能直接用
FLOOR/CEIL，而应结合SIGN和ABS：例如SELECT SIGN(x) * FLOOR(ABS(x))模拟向零取整 - PostgreSQL 中可直接用
TRUNC(x)；MySQL 8.0+ 支持TRUNCATE(x, 0)；但老版本 MySQL 只能手写逻辑 - 测试时务必覆盖负数用例，比如
SELECT FLOOR(-1.0), CEIL(-1.0), FLOOR(-1.1), CEIL(-1.1)
配合除法做分页/分组编号时的典型用法
常用于把行号映射到页码或批次号，例如每页 10 条，求第 N 行属于第几页（从 1 开始计数）：
SELECT row_num,
FLOOR((row_num - 1) / 10) + 1 AS page_num,
CEIL(row_num / 10.0) AS page_num_alt
FROM (SELECT 1 AS row_num UNION ALL SELECT 15 UNION ALL SELECT 20) t;
这里关键点是：/ 10.0 强制浮点除法（避免整数除法截断），否则在某些数据库（如 PostgreSQL）中 15/10 得 1，再套 CEIL 就失效了。另外 FLOOR((n-1)/size)+1 是更稳妥的“向上分组”写法，不依赖浮点精度。
- MySQL 中若列是整数类型且除数也是整数，默认做整数除法（丢弃小数），必须显式转为浮点，如
/ 10.0或CAST(n AS DECIMAL)/10 - SQLite 不支持
CEIL，需用ROUND(x + 0.499999999)近似（但有边界误差），建议改用(x + 9) / 10这类整数技巧替代 - 如果字段含
NULL，FLOOR(NULL)和CEIL(NULL)均返回NULL，无需额外判断，但下游逻辑要能处理
性能与类型隐式转换陷阱
这两个函数本身开销极小，但不当使用可能触发意外类型转换，影响索引利用或计算精度。例如在 WHERE 条件中写 FLOOR(price) = 10，若 price 是 DECIMAL(10,2)，数据库仍可能走全表扫描——因为函数应用在列上，无法直接命中 price 的索引。
- 优先考虑是否能改写为范围查询：
WHERE price >= 10 AND price ，这样可走索引 - 若输入是字符串（如
'12.34'），多数数据库会隐式转为数字再计算，但 SQLite 可能直接报错或返回 0，务必先CAST(x AS NUMERIC) - BigQuery 中
FLOOR对BIGNUMERIC支持良好，但旧版可能不支持高精度小数，遇到Invalid argument to FLOOR错误时需检查数据精度
真正麻烦的从来不是函数本身，而是你没意识到它在负数、整数除法、NULL 和索引友好性上的连锁反应。
