先说几个核心判断：MySQL里并不存在一个可以直接调用的AGE()函数；直接使用TIMESTAMPDIFF(YEAR, birth_date, CURDATE())计算年龄，表面上看起来正确，但一旦用户的生日还没到，结果就会多出一岁。这个陷阱，很多新手都踩过。
真正可靠的做法，是用月份差作为中间层。具体来说，就是FLOOR(TIMESTAMPDIFF(MONTH, birth_date, CURDATE()) / 12)。因为月份的计算天然是向下取整的，所以这个结果就是你想要的整岁数，与我们日常认知中的“年龄”完全一致。逻辑清晰，理解起来也很简单。唯一需要注意的是，birth_date字段必须是DATE或DATETIME类型，而且那些NULL值会导致整行数据被“抛弃”，所以提前用WHERE birth_date IS NOT NULL过滤一下，是个好习惯。
别再写一堆CASE WHEN了，用除法归类更省心
很多人的第一反应是用CASE WHEN age BETWEEN 0 AND 17 THEN '0-17' ... END来划分年龄段。这种写法确实直观，但一旦业务需求发生变化，比如要把“0-17”改成“0-15”，你就得挨个修改那一长串CASE语句，维护起来真的很痛苦。
更聪明的做法是把年龄和除数绑定在一起。FLOOR(age / 10) * 10这个公式，能把0-9岁的孩子归到0，10-19岁的少年归到10，20-29岁的青年归到20，以此类推。这就像给年龄打上了标签。再配合CONCAT函数，就能拼出像“20-29”这样的区间标签了。
不过，有一个边界情况需要单独处理。比如你想单独把“65岁以上”的人群拎出来，直接套用除法归类，它就会把65岁的人归到“60-69”这个组里。所以，这种特殊分组，需要在CASE语句里做优先判断：WHEN age >= 65 THEN '65+'，先把它截胡处理掉。
GROUP BY里的坑：别指望直接写别名
很多人写完SELECT ..., CONCAT(...) AS age_group，然后顺手就在GROUP BY后面写了个age_group，结果要么报错，要么分组完全错乱。这是因为MySQL（特别是旧版本）不允许在GROUP BY里直接引用SELECT中的别名。
那该怎么办？最稳妥的做法，是老老实实把计算表达式在GROUP BY里面再写一遍，比如GROUP BY FLOOR(TIMESTAMPDIFF(MONTH, birth_date, CURDATE()) / 12) / 10。或者，你也可以偷个懒，用列的位置编号，比如GROUP BY 3（假设年龄分组是查询结果的第三列）。不过，后一种做法可读性确实很差，万一以后改了字段顺序，这个语句就废了。
虽然最新的MySQL 8.0版本已经支持在GROUP BY里用别名了，但数据库环境没有统一升级之前，还是别去赌这个，老老实实把表达式写完整，才是真正的“稳”。
性能瓶颈在哪？先看看birth_date字段的索引
带函数的查询（比如TIMESTAMPDIFF）有一个致命缺陷：它会让你在birth_date字段上建的索引完全失效。索引一旦失效，数据库就只能走全表扫描，数据量一上来，性能立刻崩盘。
解决思路很清晰：加一个生成列（Generated Column）。比如ALTER TABLE users ADD COLUMN age INT AS (FLOOR(TIMESTAMPDIFF(MONTH, birth_date, CURDATE()) / 12)) STORED;。这相当于在表里新增了一列，但这个列的值是由其他字段动态计算出来的。然后，再对生成的列做索引：CREATE INDEX idx_users_age ON users(age);。这样，之后所有按年龄分组、筛选的操作，就都能走索引了，性能会有一个质的飞跃。
不过需要提一嘴的是，这个生成列的值是在查询时实时计算的，不会自动更新。如果业务要求年龄精确到“当天”，那就得配合定时任务每天刷新一下，或者接受一个小的误差。
回到业务本身。在真实的报表系统里，字段命名、空值处理、边界定义（比如18岁到底算青年还是成年？）这些细节，往往比一句SQL的语法更重要。语法写对了只是基础，能把业务逻辑和数据库特性结合起来，才算真正把事儿办明白了。
