最可靠计算年龄用TIMESTAMPDIFF(YEAR, birth_date, CURDATE())，因它按完整年份间隔计算，避免生日未到却多算1岁；需确保birth_date为DATE/DATETIME类型、处理NULL和非法值，并将年龄筛选条件转为birth_date静态范围以走索引。
MySQL中用TIMESTAMPDIFF计算年龄最可靠
直接用TIMESTAMPDIFF(YEAR, birth_date, CURDATE())，不是减法也不是YEAR(NOW()) - YEAR(birth_date)。后者在生日还没到的年份会多算1岁，比如2025-03-15出生的人，在2025-01-01时用减法会得1岁，实际是0岁。
原因在于TIMESTAMPDIFF按完整年份间隔计算，自动对齐日期逻辑：它比较的是“从出生日到当前日是否已满N整年”，而非单纯年份相减。
- 必须用
YEAR作为第一个参数，不能写'year'（字符串）或year（未加引号会报错） -
birth_date字段类型应为DATE或DATETIME；若为CHAR/VARCHAR，需先用STR_TO_DATE()转换，否则结果恒为NULL - 当前时间用
CURDATE()比NOW()更稳妥——避免因DATETIME中的时分秒引发边界误判
处理NULL出生日期和非法日期
生产环境里birth_date常为空或存了'0000-00-00'这类非法值，直接套用TIMESTAMPDIFF会返回NULL，可能污染聚合结果（如AVG()跳过这些行却不提醒）。
- 用
IFNULL(birth_date, '1970-01-01')兜底，但注意：填太早的日期会导致年龄异常大，更适合填一个业务可接受的默认值（如'1900-01-01'再配合WHERE过滤） - 用
STR_TO_DATE(birth_date, '%Y-%m-%d')可把格式混乱的字符串转为日期，失败时返回NULL，再结合IS NOT NULL筛选 - 检查非法日期：
birth_date < '1900-01-01' OR birth_date > CURDATE()建议在WHERE里排除，避免计算出负数或超大年龄
需要按月/天粒度算年龄时别硬套YEAR
如果需求是“用户已怀孕多少周”或“距离18岁生日还剩几天”，继续用TIMESTAMPDIFF(YEAR, ...)就错了。该函数支持MONTH、DAY、WEEK等单位，但要注意语义差异：
-
TIMESTAMPDIFF(MONTH, '2024-01-31', '2024-02-28')返回0（不足整月），而TIMESTAMPDIFF(DAY, ...)返回28 - 跨月计算时，月末日期可能被自动归整（如
'2024-01-31' + INTERVAL 1 MONTH变成'2024-02-29'，但2024年2月只有29天，实际得'2024-02-29'；非闰年则变成'2023-02-28'） - 真要算“剩余天数”，用
DATEDIFF('2025-05-20', CURDATE())更直白，DATEDIFF只认天，不涉及月份长度问题
在WHERE条件里用年龄筛选性能很差
写WHERE TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) >= 18会导致全表扫描——因为birth_date字段无法走索引（函数包裹后索引失效）。线上千万级用户表执行一次可能卡几秒。
正确做法是把动态计算转成静态范围：
- 算出18年前的日期：
DATE_SUB(CURDATE(), INTERVAL 18 YEAR) - 改写条件为：
WHERE birth_date <= DATE_SUB(CURDATE(), INTERVAL 18 YEAR) - 确保
birth_date字段有索引（普通B+树索引即可），这样能走索引范围查询 - 同理，查“年龄在18–25岁之间”应转为：
birth_date BETWEEN DATE_SUB(CURDATE(), INTERVAL 25 YEAR) AND DATE_SUB(CURDATE(), INTERVAL 18 YEAR)
真正麻烦的是那些需要精确到天的场景——比如判断“今天是否是用户生日”，MONTH(birth_date) = MONTH(CURDATE()) AND DAY(birth_date) = DAY(CURDATE())虽可用，但MONTH/DAY函数仍会让索引失效；更优解是提前在表里加个birth_month_day生成列并建索引。
