age函数返回interval类型而非整数年份,如age('2025-04-01','2000-05-15')得“24 years 10 mons 17 days”;不可直接与整数比较,需用extract(year from ...)提取年份,但不处理月份进位;判断满18周岁应改用birth_date + interval '18 years'。

AGE函数返回的是interval类型,不是整数年份
PostgreSQL的AGE函数本质是做日期减法,结果是interval(时间间隔),不是“多少岁”这种整数。比如AGE('2025-04-01', '2000-05-15')返回24 years 10 mons 17 days,不能直接用于WHERE条件比较或GROUP BY分组。
常见错误是写成WHERE AGE(birth_date) > 18——这会报错,因为interval无法和整数直接比较。
- 要提取完整年份,必须配合
EXTRACT(YEAR FROM ...),但注意:它只取interval中的year字段,不考虑月份进位(例如17 years 11 mons仍被算作17) - 若需“满18周岁”的业务逻辑,应改用
birth_date + INTERVAL '18 years' -
AGE()有两个签名:AGE(timestamp)(计算从该时间到当前时刻的差)和AGE(timestamp, timestamp)(两时间相减),别混淆参数顺序
用EXTRACT(YEAR FROM AGE())有精度陷阱
很多人用EXTRACT(YEAR FROM AGE(CURRENT_DATE, birth_date))想快速得年龄,但这个值在生日当天才更新,其余时间都偏小。比如某人出生于2000-03-15,到2025-03-14时,AGE返回24 years 11 mons 30 days,EXTRACT(YEAR FROM ...)仍返回24;到2025-03-15才跳到25。
这不是bug,是interval设计使然——它保留了原始月份/天数结构,不自动规整为“总年数”。
- 如果只要粗略年份(如统计报表),这个方式可接受
- 如果用于权限控制、资格校验(如“必须年满18”),必须用日期比较:
birth_date - 注意时区:所有参与
AGE的timestamp最好统一为timestamptz,避免因本地时区导致跨日偏差
替代方案:用CURRENT_DATE - birth_date再除以365.25更不准
有人尝试(CURRENT_DATE - birth_date) / 365.25转成年份,这是危险操作。PostgreSQL中两个date相减得到的是整数天数(integer),除法结果是numeric,但365.25只是平均值,无法处理闰年、2月天数浮动、以及“是否已过生日”这类逻辑。
- 2000-02-29出生的人,在2024-02-28时实际未满24周岁,但该公式会算出≈23.999,向下取整变23,错误
- 数据库不会帮你做“生日判断”,它只做数值运算
- 真正健壮的做法永远是:把年龄判断转回日期比较,而不是把日期转成数字再比
生产环境建议直接用日期偏移判断
绝大多数需要“年龄≥N”的场景,根本不需要算出具体数字。用birth_date 既准确、又走索引(如果<code>birth_date有索引)、还规避了所有interval解析歧义。
- 例如查18岁以上用户:
WHERE birth_date - 要查“正好18岁零3个月”,写成
birth_date = CURRENT_DATE - INTERVAL '18 years 3 months' - 如果非得输出整数年龄列供前端展示,再用
EXTRACT(YEAR FROM AGE(CURRENT_DATE, birth_date)),但别拿它做条件
真正难的不是怎么调用AGE,而是意识到:数据库里“年龄”不是属性,而是依赖当前日期的动态计算结果;把它固化成数字,就埋下了逻辑漂移的隐患。










