PostgreSQL时间函数与时间计算实战：从类型到SQL优化全解析

做了这么多年数据库相关工作，每天跟各种SQL打交道，最常被同事问到的就是“这个时间字段怎么截到天”、“这两个时间差了多少个月”、“报表要按周汇总怎么写”。PostgreSQL的时间函数确实是个很实用的知识点，但文档写得比较零散，网上搜到的例子也常常只讲单个函数，真到了组合使用的时候还得自己拼半天。这篇就把我平时用得最多、踩过坑最多的时间函数与时间计算相关内容整理出来，从基础类型到字段提取、从时间偏移到间隔计算、再从格式化到常见坑位排查，一次性梳理清楚，希望能帮你少走点弯路。

1. 先从数据类型说起：搞清楚时间到底怎么存的

很多人在时间函数上出错，根子不在函数本身，而是没搞清楚PostgreSQL里到底有哪几种时间类型。这块我吃过亏，先说清楚，后面讲函数才不会晕。

PostgreSQL的时间类型主要有这些：

这里最关键也最容易混淆的是 timestamp 和 timestamptz 的取舍。timestamp without time zone 存的就是字面意义上的时间，你写入 2025-01-15 14:30:00，查出来还是这个值，不关心你人在哪个时区；而 timestamptz 存储时会自动把输入统一换算成UTC存储，查询时再按会话的 TimeZone 参数显示成对应时区的本地时间。

我实际项目里遇到过这样的问题：业务方说“我们统一用北京时间”，然后表结构建成了 timestamp，结果后来业务扩展到海外，用户看到的上线时间全乱了。所以只要业务有跨时区的可能性，哪怕今天没有，我也建议直接用 timestamptz。存储上它只多占几个字节，但省掉的是无穷无尽的时区换算麻烦。

另一个容易忽略的点是 interval 不只是 interval '1 day' 这种简写，它还支持 interval '1 year 2 mons 3 days 04:05:06' 这种复合写法。在处理账单周期、会员有效期这类需要精确控制“几年几月几天”的场景时，复合写法比单写一个天数要精确得多，因为月和年的长度本身是可变的。

做表设计时的建议是这样：

• 业务全局统一时间的，用 timestamptz，别犹豫；
• 只记录自然日（比如 birthday、trade_date）用 date；
• 只关心时刻不关心日期（比如 open_time）用 time；
• 需要计算时间跨度，优先使用 interval 类型保存结果，而不是自己换算成秒数或天数。

数据类型定对了，后面用函数时基本不会出现“类型不匹配”的诡异报错，很多所谓“函数没生效”的问题其实都是隐式类型转换在背后捣乱。

2. 字段提取：从时间戳里拿出年、月、日、时、分、秒

2.1 最常用的extract表达式

PostgreSQL 里提取时间字段最直接的方式是 EXTRACT(field FROM source)，其中 field 可以是 year、month、day、hour、minute、second、dow、doy、week、quarter 等等，source 一般是时间戳或日期类型。它返回的是一个数值类型（numeric），适合直接参与运算。

举几个最常见的例子：

sql复制SELECT
    EXTRACT(YEAR FROM TIMESTAMP '2025-06-18 14:30:45') AS year_part,      -- 2025
    EXTRACT(MONTH FROM TIMESTAMP '2025-06-18 14:30:45') AS month_part,    -- 6
    EXTRACT(DAY FROM TIMESTAMP '2025-06-18 14:30:45') AS day_part,        -- 18
    EXTRACT(HOUR FROM TIMESTAMP '2025-06-18 14:30:45') AS hour_part,      -- 14
    EXTRACT(MINUTE FROM TIMESTAMP '2025-06-18 14:30:45') AS minute_part,  -- 30
    EXTRACT(SECOND FROM TIMESTAMP '2025-06-18 14:30:45') AS second_part;  -- 45

有一点要特别注意：EXTRACT(SECOND ...) 返回的是带小数的秒，比如 45.5，因为 PostgreSQL 的 timestamp 精度可以到微秒。如果你在报表里对比“秒”字段，最好 ROUND(EXTRACT(SECOND FROM ...)) 一下，或者直接截断到整数。

EXTRACT(DOW FROM ...) 返回的是星期几的数字，范围是 0（周日）到 6（周六），不是国内习惯的“周一=1”。如果你要做周报统计，判断“是不是周一”时，正确写法是 EXTRACT(DOW FROM create_time) = 1，而不是 = 2，这个我最初写错过好几次。如果你希望按“周一作为一周第一天”来算周数，还需要配合 date_trunc 或者 iso 相关的周逻辑来处理。

EXTRACT(DOY FROM ...) 返回的是这一年的第几天，范围 1~366。这个在做同比分析时很有用，比如去年第100天的销售额和今年第100天对比。但要注意闰年的影响，直接拿 doy 对比在跨年时会有偏差，更严谨的做法是先把日期对齐到同一年再算。

还有一个实用字段是 quarter，返回季度号：1~3 是Q1，4~6 是Q2，依此类推。做季度报表时不需要自己用月份除3取整，直接 EXTRACT(QUARTER FROM create_time) 就行。

2.2 date_part与extract的关系

DATE_PART('field', source) 函数和 EXTRACT(field FROM source) 功能几乎完全等价，唯一区别是参数顺序和“风格”。DATE_PART 是传统写法，第一个参数是文本字符串，第二个是时间值；EXTRACT 是SQL标准写法，更符合现代SQL习惯。我个人推荐统一用 EXTRACT，理由有三：一是它是SQL标准的一部分，以后迁库到MySQL 8、Oracle 19c+ 时改动最小；二是写法上更直观，EXTRACT(YEAR FROM ts) 一眼就能看出意图；三是函数名写起来更短，编码时省事。旧项目里看到 DATE_PART 也不用急着改，它不会废弃，只是风格老一点。

但 DATE_PART 有个场景还是无法替代的：当你要提取的“字段名”本身是动态的、来自用户输入或配置项时，EXTRACT 的语法写不了动态字段，DATE_PART 却可以这样用：

sql复制-- 动态提取字段：field_name 存放 'year'、'month' 等值
SELECT DATE_PART(field_name, created_at) FROM orders;

2.3 用to_char做更自由的格式化提取

EXTRACT 适合提取单一数值字段，但如果提取的结果需要拼成字符串，比如“2025年第25周”“2025年06月18日”，那就该用 TO_CHAR。它本质上不是提取函数，但实际效果比 EXTRACT 更灵活：

sql复制SELECT
    TO_CHAR(NOW(), 'YYYY') AS year_str,             -- 2025
    TO_CHAR(NOW(), 'YYYY-MM-DD') AS date_str,       -- 2025-06-18
    TO_CHAR(NOW(), 'HH24:MI:SS') AS time_str,       -- 14:30:45
    TO_CHAR(NOW(), 'YYYY-MM-DD HH24:MI') AS dt_str, -- 2025-06-18 14:30
    TO_CHAR(NOW(), 'IW') AS iso_week_str,           -- ISO周数
    TO_CHAR(NOW(), 'DY') AS day_abbr;               -- 周三（取决于语言环境）

TO_CHAR 的格式串很丰富，常见的有：

• YYYY：四位年份
• MM：两位月份（01~12）
• DD：两位日期（01~31）
• HH24 / HH12：24小时制 / 12小时制
• MI：分钟
• SS：秒
• IW：ISO 8601 周数（一年中的第几周，周一为一周起点）
• D：星期几的数字（1=周日，7=周六，注意这里和 EXTRACT(DOW) 的起始值不一样）
• ID：ISO 星期几的数字（1=周一，7=周日）

TO_CHAR 返回的是文本类型，如果后续要排序或参与数值计算，记得再包一层 ::int 或 ::numeric。我看到过有人拿 TO_CHAR(ts, 'YYYY-MM-DD') 的结果直接 ORDER BY，这其实没问题，因为字符串排序和日期排序恰好一致；但要是 TO_CHAR(ts, 'MM-DD-YYYY') 再去排序，就全乱套了。

3. 时间计算：当前时间、加减偏移与日期调整

3.1 获取当前时间：now、current_timestamp、clock_timestamp

PostgreSQL里获取当前时间有好几个函数，很多新手分不清：

sql复制SELECT NOW();                          -- 当前事务开始时间，timestamptz
SELECT CURRENT_TIMESTAMP;              -- 等价于 NOW()
SELECT CURRENT_DATE;                   -- 当前日期，date 类型
SELECT CURRENT_TIME;                   -- 当前时间（带时区），timetz 类型
SELECT LOCALTIMESTAMP;                 -- 当前事务开始时间，无时区 timestamp
SELECT CLOCK_TIMESTAMP();              -- 实际当前时刻，随调用变化

NOW() 返回的是当前事务开始的时间戳，这一点很关键。在同一个事务里（比如一个存储过程或一个批量脚本里），多次调用 NOW() 返回的值是相同的，这样能保证同一事务内的所有记录使用同一个“当前时间”，避免在长事务中时间漂移。而 CLOCK_TIMESTAMP() 返回的是真实调用时刻，每次调用都不同，适合用在需要精确计时的场景，比如计算某段SQL执行的耗时：SELECT CLOCK_TIMESTAMP() - 操作开始时的clock_timestamp()。

实际开发中，我建议：业务字段默认值用 NOW() 或 CURRENT_TIMESTAMP；调试、计时、比较两个操作间隔用 CLOCK_TIMESTAMP()；只关心日期不关心时间就用 CURRENT_DATE。

3.2 时间加减：直接运算interval

PostgreSQL 中时间加减最直观的写法就是 时间 +/- interval。interval 可以写在前面也可以写在后面，语义都一样：

sql复制-- 当前时间加/减
SELECT NOW() + INTERVAL '1 day';        -- 明天这个时刻
SELECT NOW() - INTERVAL '2 hours';      -- 两小时前
SELECT NOW() + INTERVAL '30 minutes';   -- 半小时后
SELECT NOW() + INTERVAL '1 mon';        -- 下个月同一天（注意月末问题）

-- 日期类型加/减
SELECT CURRENT_DATE + INTERVAL '7 days';  -- 得到 timestamp，不是 date
SELECT CURRENT_DATE + 7;                  -- 得到 date，整数加天数

这里有个容易翻车的坑：date + interval 的结果类型是 timestamp，不是 date。如果你定义了一个变量或字段是 date 类型，直接把 CURRENT_DATE + INTERVAL '7 days' 赋给它，会报错或者需要隐式转换。如果只是纯粹加 N 天，用 CURRENT_DATE + 7 更省事，因为整数直接代表天数。但如果你要加的是“1个月”，只能走 interval，因为“一个月”到底是多少天是不固定的。

时间减法也支持两个时间直接相减，这个放到下一节详细说。这里顺带提一句：timestamp 之间不能直接相加（逻辑上没意义），但 timestamp + interval 是可以的，timestamp - interval 也可以。PostgreSQL 在这点上对用户的保护做得算到位，报错信息也比较清晰。

3.3 日期调整：date_trunc和date_bin

DATE_TRUNC('field', source) 的语义是把时间截断到指定的精度，返回结果是 timestamp。比如 DATE_TRUNC('day', NOW()) 返回当天零点，DATE_TRUNC('month', NOW()) 返回本月1号零点。这个函数在做时间分组统计时是绝对的利器：

sql复制-- 按天统计订单数
SELECT DATE_TRUNC('day', created_at) AS day,
       COUNT(*)
FROM orders
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY 1
ORDER BY 1;

-- 按小时统计日志量
SELECT DATE_TRUNC('hour', log_time) AS hour_bucket,
       COUNT(*)
FROM access_log
GROUP BY 1
ORDER BY 1;

相比 GROUP BY TO_CHAR(created_at, 'YYYY-MM-DD')，DATE_TRUNC 的好处是返回的还是时间类型，后续可以直接参与排序、比较和进一步的时间运算，而且按时间范围过滤时能直接走索引。我之前接手过一个慢查询报表，原本就是 GROUP BY TO_CHAR(created_at, 'YYYY-MM-DD')，改成 DATE_TRUNC('day', created_at) 后，分组键可以走索引，查询时间从秒级降到了毫秒级。

DATE_BIN 是PostgreSQL 14引入的函数，用于把时间对齐到任意步长的桶里。这个函数的语法是 DATE_BIN(stride, source, origin)，stride 是步长间隔（interval 类型），source 是要对齐的时间，origin 是参考起点。比如把时间对齐到15分钟：

sql复制SELECT DATE_BIN(INTERVAL '15 minutes', NOW(), TIMESTAMP '2000-01-01 00:00:00');

这个函数当初主要面向时序数据库的场景，比如监控数据按5分钟、1小时聚合。如果只是整点、整日对齐，DATE_TRUNC 就够了；但如果步长是“7天”“3小时”“90秒”这种非标准单位，就必须用 DATE_BIN。

3.4 生成时间序列：generate_series

GENERATE_SERIES 不是严格意义上的时间函数，但做时间计算时极其常用。它可以生成一个从起点到终点、按指定步长递增的时间序列，通常用于补全缺失日期、生成日历表：

sql复制-- 生成最近7天的日期序列
SELECT GENERATE_SERIES(CURRENT_DATE - 6, CURRENT_DATE, '1 day')::date AS day;

-- 生成一天内每个整点
SELECT GENERATE_SERIES(
    DATE_TRUNC('day', NOW()),
    DATE_TRUNC('day', NOW()) + INTERVAL '1 day' - INTERVAL '1 second',
    INTERVAL '1 hour'
) AS hour_point;

实际报表中经常会遇到“某天没有数据”导致的折线图断点问题。解决思路就是先 GENERATE_SERIES 生成完整日期序列，再 LEFT JOIN 业务表，最后用 COALESCE 把空值补成0。这个模式我几乎在每个看板类项目里都写过一遍，可以说是时间函数实战中的“地基”。

4. 间隔提取：两个时间点之差怎么算最准

4.1 时间直接相减与age函数

PostgreSQL 中两个 timestamp 直接相减，得到的是 interval 类型。比如：

sql复制SELECT
    TIMESTAMP '2025-06-18 12:00:00' - TIMESTAMP '2025-06-17 10:00:00' AS diff;  
    -- 结果：1 day 02:00:00

如果你想把这个间隔转换成秒数或天数，有几种方式：

sql复制SELECT
    EXTRACT(EPOCH FROM (end_time - start_time)) AS diff_seconds,      -- 总秒数
    EXTRACT(EPOCH FROM (end_time - start_time)) / 60 AS diff_minutes, -- 总分钟
    EXTRACT(EPOCH FROM (end_time - start_time)) / 3600 AS diff_hours; -- 总小时

EXTRACT(EPOCH FROM interval) 返回的是该间隔的总秒数，会包含小数部分（微秒）。在计算耗时、RT（响应时间）等指标时，这个用法最直接。

如果要算两个日期之间跨了多少个月或多少年，AGE(end_date, start_date) 更合适。它返回的是“年-月-日”格式的间隔：

sql复制SELECT AGE(TIMESTAMP '2025-06-18', TIMESTAMP '2023-01-10');
-- 结果：2 years 5 mons 8 days

AGE(end_date, start_date) 和 end_date - start_date 的差异在于：直接相减会把总天数累计出来（比如 876 days），而 AGE 会把天数拆成年月日（比如 2 years 4 mons 26 days）。两者应用场景不同：统计跨度的“总量”（比如累计在线时长）用直接相减加 EXTRACT(EPOCH ...)；描述“年龄”“工龄”“会员时长”这种你希望“以人类可读的方式展示”的，用 AGE。

AGE 还有一个极易踩的坑：只传一个参数时 AGE(ts) 等价于 AGE(NOW(), ts)，即从 ts 到当前时间的年龄。我遇到过有人写 AGE(start_time, end_time) 把参数顺序传反了，结果出来负数。PostgreSQL 不报错，因为 interval 负数合法，但业务上就出笑话了。建议统一约定：AGE(大的时间, 小的时间)，并且在使用前用 GREATEST / LEAST 保护一下。

4.2 判断时间差是否超过阈值

业务里常见的需求是“超过30分钟未支付就关单”“超过3天未激活就发提醒”。这类判断不需要把间隔算成具体数值再比较，直接让 interval 跟 interval 比就行：

sql复制-- 找出等待超过30分钟未支付的订单
SELECT order_id, created_at
FROM orders
WHERE status = 'pending'
  AND NOW() - created_at > INTERVAL '30 minutes';

这种写法简洁且走得了索引（只要 created_at 上有索引），不要去写成 EXTRACT(EPOCH FROM (NOW() - created_at)) / 60 > 30，性能没有提升，可读性还更差。

不过要注意：NOW() - created_at 这种写法在 created_at 是 timestamptz 时没问题，但如果 created_at 是 timestamp without time zone，减号右边的 NOW() 返回的又是 timestamptz，PostgreSQL 会自动做一次隐式转换，可能会产生时区偏差。稳妥的做法是统一类型：要么字段都用 timestamptz，要么比较时手动把 NOW() 转成同一类型：NOW()::timestamp - created_at。这个低级错误我在生产环境里排查过不止一次，查出来的原因就是把 timestamp 和 timestamptz 混着用了。

4.3 工作日与业务日历：排除周末的简单方案

严格的计算工作日天数比较复杂（涉及法定节假日、调休），但如果只是排除周末，PostgreSQL 可以这样算：

sql复制-- 计算两个日期之间的工作日天数（不包含两端? 根据需求调整）
SELECT
    COUNT(*) AS workdays
FROM GENERATE_SERIES(
    '2025-06-01'::date,
    '2025-06-30'::date,
    '1 day'
) AS d(day)
WHERE EXTRACT(ISODOW FROM d.day) < 6;

EXTRACT(ISODOW FROM ...) 返回的是 1（周一）到 7（周日），所以 < 6 就过滤掉了周六日。这里更推荐用 ISODOW 而不是 DOW，因为 ISODOW 的语义更符合国内习惯（周一=1），不容易搞混。如果需要排除法定节假日，可以把节假日日期存在一张维表里，然后用 NOT EXISTS 去过滤。

这个方案虽然简单，但我司实际报表里经常能省下大量手工计算。之前有同事用 Excel 算工作日，每次还要手动标记节假日，迁移到 PostgreSQL 之后，一条 SQL 搞定，误差还小很多。

5. 格式化与转换：字符串和时间互转的方法

5.1 to_char格式化输出

TO_CHAR 除了用于字段提取，也是格式化输出的主选。它可以控制日期时间显示成任意格式，我常用的一些格式串：

sql复制SELECT
    TO_CHAR(NOW(), 'YYYY-MM-DD') AS date_only,
    TO_CHAR(NOW(), 'YYYY/MM/DD') AS date_slash,
    TO_CHAR(NOW(), 'YYYY年MM月DD日') AS date_cn,
    TO_CHAR(NOW(), 'HH24:MI:SS') AS time_24h,
    TO_CHAR(NOW(), 'HH12:MI:SS AM') AS time_12h,
    TO_CHAR(NOW(), 'YYYY-MM-DD HH24:MI:SS') AS full_format;

报表导出时，用户通常希望看到 2025-06-18 14:30:00 这样的标准格式，但有时也要 2025年6月18日 这种中文展示。TO_CHAR 都能满足。需要注意 TO_CHAR 返回的是 text，如果要按时间排序、按时间过滤，尽量在底层保留时间类型，放到展示层再转字符串，避免在SQL中反复转换影响性能。

5.2 字符串转时间戳：to_timestamp、to_date、cast

字符串转时间在数据清洗、外部数据导入时几乎必然出现。三个函数的使用边界不同：

sql复制-- to_timestamp：字符串转 timestamptz
SELECT TO_TIMESTAMP('2025-06-18 14:30:45', 'YYYY-MM-DD HH24:MI:SS');
SELECT TO_TIMESTAMP('2025-06-18', 'YYYY-MM-DD');

-- to_date：字符串转 date
SELECT TO_DATE('2025/06/18', 'YYYY/MM/DD');
SELECT TO_DATE('20250618', 'YYYYMMDD');

-- 简写风格：直接 cast
SELECT '2025-06-18 14:30:45'::timestamp;
SELECT '2025-06-18'::date;

TO_TIMESTAMP 有两个重载：一个参数时，它会把字符串按默认格式解析；两个参数时，第一个是字符串，第二个是格式模板。这里的格式模板和 TO_CHAR 的格式串是对应的，但要注意有些格式串只能单向用。例如 TO_CHAR 可以输出 TZ（时区缩写），但 TO_TIMESTAMP 对 TZ 的解析支持很弱，遇到 2025-06-18 14:30:00 CST 这种带时区缩写文本时，建议先把时区部分去掉，或者转成 +08 这种数值格式再解析。

实际数据清洗中，我常遇到“脏数据”混着多种日期格式，比如有的行是 2025/06/18，有的行是 2025-6-8，还有的是 20250618。我的做法是：先把字段 trim 掉空字符，然后 CASE WHEN 按长度和分隔符判断格式，再调对应的转换函数。这一步做不好，后面所有时间计算都是错的，所以字符串转时间一定要在入库阶段就做严格校验，宁可让ETL报错也不要放过坏数据。

5.3 epoch时间戳与时间互转

epoch 是指从 1970-01-01 00:00:00 UTC 到某个时间点的秒数。很多外部接口和物联网设备传时间都用epoch秒或毫秒。PostgreSQL 的转换方法：

sql复制-- 时间戳转 epoch 秒
SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2025-06-18 14:30:00+08');
SELECT EXTRACT(EPOCH FROM NOW());

-- epoch 秒转回时间戳
SELECT TO_TIMESTAMP(1750235400);
SELECT TO_TIMESTAMP(1750235400.123);  -- 带毫秒

-- epoch 毫秒转时间戳
SELECT TO_TIMESTAMP(1750235400123 / 1000.0);

这里有个常见坑：如果设备传的是“毫秒”值，直接 TO_TIMESTAMP(1750235400123) 会得到一个极其遥远的未来时间，因为 TO_TIMESTAMP 的单位是“秒”。需要先除以 1000.0 再转。如果是13位的“epoch毫秒”且数据量很大，还可以先把整数部分和小数部分拆开处理，避免浮点精度问题。

还有一点容易踩：EXTRACT(EPOCH FROM timestamp_without_time_zone) 时，PostgreSQL 会把该无时区时间假定为当前会话时区下的时间，再换算成UTC epoch。如果数据库会话时区是 UTC，而业务默认上海时间，得到的epoch就会差8小时。稳妥做法是先把字段转成 timestamptz 再提取epoch，或者统一约定会话时区。说实话，这也是我在生产环境里第一次排查“时间差8小时”问题时发现的原因。

6. 时间计算实战：需求到SQL的完整转换

6.1 场景一：日报、周报、月报的时间范围

“取昨天全天的数据”“取本周一到今天的数据”“取本月至今的数据”，这些是报表需求里出现频率最高的话。对应SQL写法：

sql复制-- 昨天全天：范围是 [昨天00:00, 今天00:00)
SELECT *
FROM orders
WHERE created_at >= CURRENT_DATE - 1
  AND created_at < CURRENT_DATE;

-- 本周（周一到今天）
-- 思路：先取本周一的日期，再 range 到今天
WHERE created_at >= DATE_TRUNC('week', CURRENT_DATE)   -- 注意：PG中一周起点是周一
  AND created_at < DATE_TRUNC('day', CURRENT_DATE) + 1;

-- 本月至今
WHERE created_at >= DATE_TRUNC('month', CURRENT_DATE)
  AND created_at < DATE_TRUNC('day', CURRENT_DATE) + 1;

注意 DATE_TRUNC('week', CURRENT_DATE) 返回的是本周一的零点，这是PostgreSQL的ISO周习惯，和国内认知一致。但如果你用的是 TO_CHAR(CURRENT_DATE, 'IW') 取第几周，会有跨年周的问题，需要注意边界。

写时间范围条件时的两个原则：一是“大于等于起始，小于结束”，不要用 BETWEEN ... AND ... 去包含结束时间，因为结束时刻一般是 00:00:00，容易漏掉最后一秒的数据；二是过滤字段上不要套函数，比如 WHERE DATE(created_at) = CURRENT_DATE 这种写法会让索引失效，应该写成范围条件。

6.2 场景二：连续日期的缺失补全

一个经典分析需求：统计最近30天每天的订单量，没有订单的日期要显示0。直接用 GROUP BY 做不会出现0，因为没数据的日期根本没有行。正确做法是先生成日期序列，再左关联：

sql复制WITH days AS (
    SELECT GENERATE_SERIES(CURRENT_DATE - 29, CURRENT_DATE, '1 day')::date AS day
)
SELECT
    d.day,
    COUNT(o.order_id) AS order_cnt
FROM days d
LEFT JOIN orders o
    ON o.created_at::date = d.day
GROUP BY d.day
ORDER BY d.day;

这条SQL看着简单，但性能上有个隐患：o.created_at::date = d.day 对 created_at 做了类型转换，可能走不了索引。如果 orders 表很大，建议改成范围连接：

sql复制ON o.created_at >= d.day
   AND o.created_at < d.day + 1

这样既能利用 created_at 上的B-tree索引，语义也更严谨。我接手过一个看板项目，原本日活统计报表每次跑20多秒，改成范围连接加索引后降到1秒内，就是这个原因。

6.3 场景三：时间序列的同比、环比计算

同比、环比在经营分析里很常见。用窗口函数可以避免自连接，写起来也更清晰。比如“每天订单量，以及对比昨天的环比”：

sql复制WITH daily AS (
    SELECT DATE_TRUNC('day', created_at)::date AS day,
           COUNT(*) AS cnt
    FROM orders
    WHERE created_at >= CURRENT_DATE - 30
    GROUP BY 1
)
SELECT
    day,
    cnt,
    LAG(cnt) OVER (ORDER BY day) AS prev_cnt,
    ROUND(
        (cnt - LAG(cnt) OVER (ORDER BY day)) * 100.0 / NULLIF(LAG(cnt) OVER (ORDER BY day), 0),
        2
    ) AS pct_change
FROM daily
ORDER BY day;

代码里用了 LAG 取出前一行数据，NULLIF 避免除零。环比数据在日报系统里几乎是标配。这里要注意 LAG 的默认值，如果没有前一行（比如第一天），结果会是 NULL，展示层的数字要处理好，比如显示成 - 而不是 NULL。

同比的话，“今年某日 vs 去年某日”这种对比更多是拿日期字段做偏移后再关联，或者直接用 ORDER BY 里的 OFFSET 思维。如果数据量不大，最简单的方式是今年的结果和去年的结果先分别算好，再 JOIN 日期字段。但更稳的写法是把 created_at 减一年，然后 JOIN 到去年的日期上：

sql复制SELECT
    this_year.day,
    this_year.cnt AS this_cnt,
    last_year.cnt AS last_cnt
FROM (
    SELECT day, cnt FROM daily WHERE ...
) this_year
LEFT JOIN (
    SELECT day, cnt FROM daily WHERE ...
) last_year
    ON last_year.day = this_year.day - INTERVAL '1 year';

这里有个坑：闰年2月29日减一年的结果在某些年份不存在（2月没有29日），PostgreSQL会自动将结果调整为2月28日，看起来没问题，但严格意义上和“同比”的语义可能略有偏差。做这类计算时，最好先明确业务上“同比日期”的定义，再决定直接用 - INTERVAL '1 year' 还是用 DATE_TRUNC 之后偏移到指定日期。

6.4 场景四：计算年龄/工龄/会员时长

计算年龄最实用的方式是 AGE 函数加 EXTRACT(YEAR FROM ...)：

sql复制-- 计算截至今天的年龄
SELECT
    name,
    birthday,
    EXTRACT(YEAR FROM AGE(CURRENT_DATE, birthday)) AS age
FROM users;

-- 计算工龄（精确到月）
SELECT
    name,
    hire_date,
    EXTRACT(YEAR FROM AGE(hire_date)) AS work_years,
    EXTRACT(MONTH FROM AGE(hire_date)) AS work_months
FROM employees;

EXTRACT(YEAR FROM AGE(...)) 和 EXTRACT(YEAR FROM NOW()) - EXTRACT(YEAR FROM birthday) 的天壤之别在于：前者会考虑当前日期是否已经过了生日，后者不会。比如某人2000年12月30日出生，到2025年1月1日，前者算出的年龄是24（因为还没过25岁生日），后者按年份差算是25。绝大多数业务场景下应该用前者，否则年龄会有虚一岁的问题。

另外还有一个更精确的写法：(CURRENT_DATE - birthday) / 365 这种写法很常见但不严谨，因为忽略了闰年，算出来偶尔会差一天。所以能用 AGE 就不要自己除365。

7. 常见问题与坑位排查

7.1 类型混用导致的时区偏移

现象：一个表的 created_at 存的是 timestamp without time zone，另一个表的 created_at 存的是 timestamptz，两个表关联统计时总是差8小时。

根因：PostgreSQL 在 timestamp 和 timestamptz 之间比较时，会自动把 timestamp 按当前会话时区解释为 timestamptz。如果会话时区是 UTC，而业务实际是东八区，就会出现8小时偏差。

排查步骤：

1. SHOW TIMEZONE; 看当前会话时区；
2. 分别查看两个字段的类型：SELECT column_name, data_type FROM information_schema.columns WHERE table_name = '...';
3. 统一类型。表结构允许的话，建议直接改字段类型，比如：

   sql复制ALTER TABLE your_table ALTER COLUMN created_at TYPE timestamptz USING created_at AT TIME ZONE 'Asia/Shanghai';
   

4. 如果不允许改表，就在比较时显式转换，比如 a.ts AT TIME ZONE 'Asia/Shanghai'。

个人经验：与其事后补救，不如建表时就统一使用 timestamptz。OLTP系统我建议全部用 timestamptz，展示层再转成本地时间，这样能少踩90%的时区坑。

7.2 interval计算中“一个月”到底等于多少天

现象：'2025-01-31'::date + INTERVAL '1 mon' 的结果是 2025-02-28，而不是 2025-03-02 或 2025-02-31（这个日期不存在）。

原因：PostgreSQL 处理 interval 加法时遵循“尽量保持月份”，即把月份部分加1，然后把日期部分截断到目标月份的最后一天。这个行为是合理的，但对不熟悉的人来说容易产生“结果怎么少了一天”的疑惑。

解决：如果你需要的语义是“固定30天后”，用 INTERVAL '30 days'；如果需要“下个月这一天”，用 INTERVAL '1 mon' 并接受月末截断。如果希望“下个月最后一天”，可以先 DATE_TRUNC('month', ts) + INTERVAL '1 mon' - INTERVAL '1 day'。

再给一个实际的建议：做账单日、还款日这类业务时，必须提前定好规则“如果账单日是31号而目标月份只有30天，按30号算还是按月末算”。PostgreSQL默认是月末，如果业务要求不同，就得在SQL里单独处理。

7.3 age函数与直接相减返回格式不同

实际使用中不要混用。比如你在一个列表页展示“开通时长”，用 AGE 比较友好；但你要用“累计秒数”做排序、过滤、告警阈值判断，就用减法加 EXTRACT(EPOCH ...)。最怕的是代码里一会儿用 AGE 一会儿用直接相减，最后数据对不上，排查起来很费劲。

7.4 to_char的格式串大小写敏感

现象：TO_CHAR(NOW(), 'YYYY-mm-dd') 出来的“月份”变成了分钟数，TO_CHAR(NOW(), 'HH24:mi:ss') 的“分钟”变成了月份。

原因：PostgreSQL 的格式串是大小写敏感的。MM 表示月份（month），MI 表示分钟（minute），HH24 表示24小时制小时，HH12 表示12小时制。写错大小写不会报错，但值就完全错了。

建议：

• 月份用大写 MM
• 分钟用小写 MI
• 小时用 HH24 / HH12
• 秒用 SS
• 年份用 YYYY 或 YY

这个坑特别隐蔽，因为结果不会报错，只是数据错了。我排查过一键生成报表的任务，月度汇总数据偶尔异常，最后发现是有人在格式串里把 MM 写成了 mm，导致月份串到了分钟列。

7.5 索引失效的时间过滤写法

不推荐：

sql复制WHERE DATE(created_at) = CURRENT_DATE
WHERE TO_CHAR(created_at, 'YYYY-MM-DD') = '2025-06-18'
WHERE EXTRACT(YEAR FROM created_at) = 2025

推荐：

sql复制WHERE created_at >= CURRENT_DATE
  AND created_at <  CURRENT_DATE + 1

WHERE created_at >= '2025-01-01'::date
  AND created_at <  '2026-01-01'::date

原因很简单：对字段套函数后，B-tree索引无法直接用于范围查找，数据库只能全表扫描。时间过滤是OLTP最常用的条件，建议写成范围条件，让优化器能用上索引。

附：常用时间函数速查表

写在最后的实操心得

PostgreSQL 的时间函数体系其实不复杂，但组合起来非常灵活。我个人最大的体会是：写时间SQL时，先想清楚“输入类型是什么、输出类型要什么”，再选择函数，能避免大多数类型不匹配和隐式转换带来的坑。另外，所有时间函数在开发环境测试通过后，务必用真实数据边界测一遍，比如月末、年末、闰日、夏令时切换日，这些日子最容易暴露问题。

如果这篇文章能帮你少写几次“为什么这个时间不对”的排查SQL，它的任务就完成了。后续有任何时间计算场景不知道怎么处理的，也欢迎留言讨论，我在实际项目里碰到过的坑都可以再展开说说。