TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) 是MySQL中计算整岁的最可靠方法，它自动处理闰年、大小月及2月29日等边界情况，避免YEAR(NOW())-YEAR(birth_date)因忽略月日导致的误差。
用 TIMESTAMPDIFF 算整岁最可靠
MySQL 中直接用 YEAR(NOW()) - YEAR(birth_date) 看似简单，但会出错：比如生日还没到的用户，年龄会多算 1 岁。真正按“满多少周岁”算，必须考虑月份和日期是否已过。TIMESTAMPDIFF 是唯一能跨年、跨月、跨日做精确差值计算的内置函数，且返回整数，不带小数。
实操写法：
SELECT TIMESTAMPDIFF(YEAR, birth_date, CURDATE()) AS age FROM users;注意三个参数顺序不能错：单位（
YEAR）、起始时间（出生日）、结束时间（当前日）。它内部自动处理闰年、大小月、2 月 29 日等边界情况。
常见错误现象：
• 把 CURDATE() 写成 NOW() —— 虽然多数时候结果一样，但 NOW() 带时分秒，可能在极少数临界时刻（如生日当天 00:00:00 前）导致结果偏差；
• 单位写成 YEAR() 或 'year' —— 必须是全大写无引号的 YEAR，否则报错或返回 NULL。
PostgreSQL 怎么办：用 AGE() + EXTRACT
PostgreSQL 没有 TIMESTAMPDIFF，但 AGE() 函数返回一个 interval 类型，需要进一步提取年份部分。直接 EXTRACT(YEAR FROM AGE(NOW(), birth_date)) 仍不严谨——因为 AGE() 返回的是“年-月-日”组合，EXTRACT(YEAR FROM ...) 只取年字段，忽略月日，会导致同 MySQL 的粗略算法一样出错。
正确做法是先算完整间隔，再判断是否已过生日：
SELECT EXTRACT(YEAR FROM AGE(CURRENT_DATE, birth_date))::INT -
CASE WHEN (CURRENT_DATE - INTERVAL '1 day' * EXTRACT(DOY FROM birth_date)::INT) < CURRENT_DATE
THEN 0 ELSE 1 END AS age
FROM users;更稳妥的写法是用 TO_CHAR 提取月日对比：SELECT EXTRACT(YEAR FROM AGE(CURRENT_DATE, birth_date))::INT -
(CASE WHEN TO_CHAR(CURRENT_DATE, 'MMDD') < TO_CHAR(birth_date, 'MMDD') THEN 1 ELSE 0 END) AS age
FROM users;这个逻辑清晰：如果今天“月日”比生日“月日”还小，说明今年生日还没到，减 1。
SQL Server 里避免 DATEDIFF 的陷阱
DATEDIFF(YEAR, birth_date, GETDATE()) 是常见误用：它只比较年份部分，不管月日，2024-01-01 到 2025-12-31 也会返回 1，完全不是实际年龄。必须手动校验生日是否已过。
推荐写法：
SELECT DATEDIFF(YEAR, birth_date, GETDATE()) -
CASE WHEN DATEFROMPARTS(YEAR(GETDATE()), MONTH(birth_date), DAY(birth_date)) > GETDATE()
THEN 1 ELSE 0 END AS age
FROM users;关键点：•
DATEFROMPARTS 重构今年的生日（避免 2 月 29 日在非闰年报错，SQL Server 2012+ 支持）；• 用重构后的日期和今天比大小，比字符串拼接或
MONTH()/DAY() 分开比更安全；• 不要用
CONVERT 拼字符串，遇到 2 月 29 日会直接报错。
为什么不能用 JavaScript 或应用层算
不是不能，而是容易漏掉数据库时区、夏令时、闰秒等隐性影响。比如应用服务器时区是 UTC+8，数据库时区是 UTC，CURDATE() 和 new Date() 可能差一天，导致年龄突变。另外批量查几百万人时，把出生日期拉到应用层再循环计算，网络传输和内存压力远大于数据库内聚合计算。
性能提示：
• 所有上述 SQL 写法都支持索引跳过（只要没对 birth_date 做函数运算，如 YEAR(birth_date) 就无法走索引）；
• 如果频繁按年龄段查询（如 “查 25–35 岁用户”），建议额外加一个 age_group 计算列并建索引，而不是每次 SELECT 都实时算。
最容易被忽略的一点：2 月 29 日出生的人，在非闰年的 2 月 28 日或 3 月 1 日算“满岁”，不同业务定义不同。SQL 层没法自动猜你的规则，必须明确写进条件里——比如按“每年 3 月 1 日视为生日”就需调整 DATEFROMPARTS 或 TO_CHAR 的逻辑。
