BETWEEN硬编码年龄段易出错，因维护困难、NULL/小数导致漏数或重复；FLOOR通过数值映射实现动态分组，需合理设计除数与偏移量，并注意数据库差异、NULL处理及索引性能。
为什么直接用 BETWEEN 划分年龄段容易出错
实际写报表时，很多人会写 WHERE age BETWEEN 0 AND 17、BETWEEN 18 AND 25 这类条件再 UNION ALL，但这样硬编码区间会导致维护困难：新增一个“65+”组就得改 SQL、加分支；年龄字段若含 NULL 或小数（比如 25.9 岁），BETWEEN 还可能漏数据或跨组重复。
FLOOR 的优势在于把连续数值映射成离散整数标签，天然支持动态分组逻辑。关键不是“用不用”，而是怎么设计除数和偏移量。
- 错误写法：
FLOOR(age / 10)→ 0–9 岁得 0，10–19 得 1，但 0 岁婴儿和 9 岁儿童被归为同一组，业务上通常不接受 - 正确思路：先统一减去下界再除，比如从 0 岁起每 10 年一档，应写
FLOOR(age / 10)；但从 1 岁起（如“1–10岁”“11–20岁”），就得用FLOOR((age - 1) / 10) - 注意：MySQL 和 PostgreSQL 的
FLOOR对负数处理一致（向负无穷取整），但若 age 字段有负值（脏数据），结果会异常，建议前置过滤WHERE age >= 0
用 FLOOR 实现标准年龄段分组的写法
国内常用年龄段划分是“0–5、6–17、18–59、60+”，这不是等宽区间，不能只靠一个 FLOOR 表达。此时要结合 CASE WHEN + FLOOR 做预分类：
SELECT
CASE
WHEN age <p>如果坚持纯 <code>FLOOR</code>（例如做快速探索性分析），可强制转为等宽：用 <code>FLOOR(age / 10)</code> 得到 0,1,2,3,4,5…，再用 <code>CASE</code> 映射为中文标签。这样改区间只需调除数，不碰分支逻辑。</p>
- 10 岁一档：
FLOOR(age / 10)→ 0→"0-9", 1→"10-19" - 5 岁一档：
FLOOR(age / 5)→ 0→"0-4", 1→"5-9" - 想让 18 岁起始（如“18-22”“23-27”），写
FLOOR((age - 18) / 5)，但需确保age >= 18，否则负数结果不可读
FLOOR 在不同数据库中的行为差异
绝大多数场景下 FLOOR 行为一致，但有两个细节必须核对：
- SQL Server 的
FLOOR要求输入是数值类型，若传字符串（如age是VARCHAR），会报错Operand data type varchar is invalid for floor operator，必须显式转换：FLOOR(CAST(age AS FLOAT)) - SQLite 没有原生
FLOOR函数，得用CAST(age AS INTEGER)替代（仅适用于非负数）；若 age 含小数且需向下取整，得写CAST(age AS INTEGER) - (CASE WHEN age - 所有数据库中，
FLOOR(NULL)永远返回NULL，所以GROUP BY FLOOR(age/10)会把NULL年龄单独成一组，记得加WHERE age IS NOT NULL
性能与索引是否受影响
直接在 WHERE 或 GROUP BY 中对字段用 FLOOR(age / 10)，会导致无法使用 age 列上的普通 B-tree 索引——因为优化器无法将函数结果反推回原始值范围。
如果查询频次高且数据量大，更优解是：在表里增加一个生成列（generated column）或冗余字段存分组码，然后建索引：
-- MySQL 5.7+ 示例 ALTER TABLE users ADD COLUMN age_decade TINYINT AS (FLOOR(age / 10)) STORED; CREATE INDEX idx_age_decade ON users(age_decade);
- 这样
GROUP BY age_decade就能走索引，速度提升明显 - PostgreSQL 可用
CREATE INDEX ON users ((FLOOR(age / 10)))创建函数索引 - 别忘了业务含义变更时（比如把“10岁一档”改成“8岁一档”），这类索引或生成列要同步调整，否则统计口径就错了
真正麻烦的从来不是怎么写 FLOOR，而是当产品突然说“把老年组从 60+ 改成 65+”，你得同时改 SQL、改报表配置、改索引、改 ETL 脚本——而这些地方，往往只有两处写了硬编码的 60。
