floor计算年龄段偏大一岁是因为year(now())-year(birth_date)未校验生日是否已过，正确做法是用timestampdiff(year,birth_date,curdate())获取精确整数年龄再分组。
用 FLOOR 计算年龄段分组时，为什么结果总偏大一岁？
因为直接用 FLOOR((YEAR(NOW()) - YEAR(birth_date)) / 10) 会忽略生日是否已过——比如 2025-03-15 出生的人，在 2025-01-01 时还没满 1 岁，但上面公式算出来是 FLOOR(0/10)=0，看似合理；可一旦到了 2026-01-01，它就变成 FLOOR(1/10)=0，仍归入“0–9 岁”，实际已满 1 岁但不足 2 岁。真正要的是“当前精确年龄”，不是“年份差”。
正确做法是先算出精确年龄，再分组：
- MySQL 中用
TIMESTAMPDIFF(YEAR, birth_date, CURDATE())得到整数年龄（自动向下取整到已满年数） - 再套
FLOOR(age / 10)或直接age DIV 10（更简洁，且避免浮点误差） - 别用
YEAR(NOW()) - YEAR(birth_date)，它不校验月份日，错误率高
写 CASE WHEN 区间分组时，边界值容易漏掉或重复
常见写法如 WHEN age >= 0 AND age 看似稳妥，但当 age 是 <code>NULL（比如出生日期缺失），整行会被排除在所有 WHEN 外，导致该记录不出现在结果中——而你可能希望它归入“未知”或单独计数。
实操建议：
- 务必加
ELSE '未知'分支，覆盖NULL和异常值 - 区间用左闭右开更安全：例如
WHEN age >= 0 AND age ，避免相邻区间因等号重叠（比如 <code> 和 <code>>=10中间没缝隙，但和 <code>>=10逻辑更清晰） - 如果业务要求“60 岁及以上”统一归类，写成
WHEN age >= 60 THEN '60+'，别漏掉ELSE之后的兜底
两种方法性能差异不大，但可读性和维护性差别明显
单纯看执行计划，FLOOR(age DIV 10) 和长串 CASE 在小表上几乎无差别；但真实场景中，后者更容易被业务方理解、修改和审计。
比如运营突然要求把“25–34 岁”单独拎出来做推送，CASE 只需加一行；而 FLOOR 方案得额外加 CASE WHEN age BETWEEN 25 AND 34 THEN '25-34' ELSE CONCAT(FLOOR(age / 10) * 10, '-', FLOOR(age / 10) * 10 + 9)，嵌套变深、易出错。
-
FLOOR适合固定步长、无需特殊区间、追求代码短的场景（如快速看分布） -
CASE适合有业务语义、区间不规则、后续要频繁调整的统计（如合规报告、用户分层） - 如果字段
birth_date没索引，两种方案都会触发全表扫描——优化重点其实是加索引，不是选函数
注意 MySQL 版本对 TIMESTAMPDIFF 的兼容性
低版本 MySQL（如 5.5）中 TIMESTAMPDIFF 对 DATE 类型支持不稳定，某些情况下返回 NULL；而 PERIOD_DIFF 又只接受 YYYYMM 格式，不够直观。
稳妥写法（兼容 5.5+）：
SELECT
CASE
WHEN birth_date IS NULL THEN '未知'
ELSE FLOOR(TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) / 10)
END AS age_group,
COUNT(*) AS cnt
FROM users
GROUP BY age_group;
但如果确定环境是 MySQL 8.0+，推荐直接用 WITH 子句先算年龄，再分组，逻辑更干净：
WITH user_ages AS (
SELECT TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) AS age
FROM users
WHERE birth_date IS NOT NULL
)
SELECT
CASE
WHEN age = 35 THEN '35+'
ELSE '未知'
END AS age_segment,
COUNT(*) AS cnt
FROM user_ages
GROUP BY age_segment;
真实上线前，一定要用含 NULL、边界日（如今天生日）、未来日期的数据集跑一遍验证——这些地方最容易在测试环境被忽略。
