AGE函数返回interval类型而非整数，直接转int会丢失月日精度；判断周岁应使用日期运算如birth_date >= CURRENT_DATE - INTERVAL '30 years'，避免AGE()导致的索引失效与边界错误。
AGE函数返回的是interval类型，不是整数年份
PostgreSQL的AGE()函数不直接给出“多少岁”这种整数结果，而是返回一个interval值，比如 25 years 3 mons 14 days。这意味着它保留了年、月、日的完整构成，但你也无法直接用WHERE age > 30这种写法——因为interval和数字不能直接比较。
常见错误是试图对AGE()结果做算术四舍五入或强制转int：(AGE(CURRENT_DATE, birth_date))::int，这会截断所有月/日信息，把29 years 11 mons 29 days也变成29，实际离30岁只差2天。
实操建议：
- 若需判断是否满N周岁，用
CURRENT_DATE - INTERVAL 'N years' >= birth_date更可靠 - 若必须用
AGE()做区间筛选（如“25–30岁之间”），应拆解为年、月、日三部分计算，或改用EXTRACT(YEAR FROM AGE())配合边界校验 -
EXTRACT(YEAR FROM AGE())只取年份字段，忽略月日，所以EXTRACT(YEAR FROM AGE('2024-01-01', '1998-12-31'))返回25，但真实年龄已满25岁零1天
用EXTRACT + DATE arithmetic做精确区间过滤
要查“真实年龄在25到30周岁之间（含）”的人，最稳妥的方式是避开AGE()，改用出生日期与当前日期的算术比较：
SELECT * FROM users WHERE birth_date <= CURRENT_DATE - INTERVAL '25 years' AND birth_date > CURRENT_DATE - INTERVAL '31 years';
注意这里是“> 31年前”，不是“>= 30年前”，因为：如果某人出生在1994-05-20，那么CURRENT_DATE - INTERVAL '30 years'是1994-05-20当天，而birth_date >= '1994-05-20'会把刚满30岁的人包含进来；但我们要的是“未满31岁且已满25岁”，即[25, 31)左闭右开区间。
关键点：
- 区间边界必须用
DATE运算，不是AGE()再转换 - 涉及闰年、月末日期（如2月29日出生）时，PostgreSQL的
INTERVAL减法会自动对齐，比手动解析AGE()的interval更健壮 - 索引友好：如果
birth_date上有B-tree索引，上述写法可走索引；而EXTRACT(YEAR FROM AGE(birth_date)) BETWEEN 25 AND 30无法利用索引
需要显示“X岁Y个月Z天”格式时，必须解析interval
当UI要求展示“27岁5个月12天”这种格式，就得处理AGE()返回的interval。但不能简单用EXTRACT全取年月日——因为interval内部存储可能归一化（如15 months存为1 year 3 mons），而EXTRACT(MONTH FROM ...)只取月字段，不包含跨年的余量。
正确做法是用EXTRACT逐级扣除：
SELECT EXTRACT(YEAR FROM age) AS years, EXTRACT(MONTH FROM age) AS months, EXTRACT(DAY FROM age) AS days FROM (SELECT AGE(CURRENT_DATE, '1996-08-15') AS age) t;
但要注意：这个结果依赖AGE()输入是否为date类型。如果传入timestamp，EXTRACT(DAY FROM ...)会包含小时/分钟的换算（1天=24小时），导致日数不准。务必统一用date类型参与计算。
容易踩的坑：
- 混用
timestamptz和date：时区偏移可能导致AGE()结果多出或少掉一天 - 用
TO_CHAR(AGE(), 'YYYY "years" MM "mons" DD "days"')——该格式化仅适用于interval输出，但字段名会被截断，且无法控制“0年”“0月”的显示逻辑 - 认为
AGE(start, end)和AGE(end, start)只是符号相反：实际上前者返回负interval，而EXTRACT对负值仍返回正数字段（如EXTRACT(YEAR FROM INTERVAL '-25 years')得25），需额外加符号判断
跨年边界和性能提醒
真实业务中，“年龄区间”常用于报表或权限控制，查询频次高。此时要注意：AGE()是运行时计算，无法被索引加速；而基于birth_date的日期范围查询可以命中索引。
如果表里有大量数据且频繁查年龄区间，建议：
- 避免在WHERE中写
EXTRACT(YEAR FROM AGE(birth_date)) BETWEEN 25 AND 30 - 建表达式索引：
CREATE INDEX idx_users_age ON users ((CURRENT_DATE - birth_date));没用，因为CURRENT_DATE是volatile函数；但可以建函数索引：CREATE INDEX idx_users_birth_year ON users (EXTRACT(YEAR FROM birth_date));，再配合年份范围估算（精度略低但快） - 真正需要精确到日的场景，接受全表扫描或加物化视图缓存年龄字段（每天凌晨刷新）
最麻烦的其实是需求本身：“精确年龄区间”听起来明确，但产品常常没想清要不要包含当天、是否按生日当日切换、跨时区用户怎么算——这些都得在SQL之外对齐，而不是指望AGE()自动解决。
