SQL日期函数实战指南：三大数据库用法、场景与避坑技巧-代码聚汇网

SQL日期函数实战指南：三大数据库用法、场景与避坑技巧

元宿six·2026-09-01·阅读 22 GEO检测（免费）

SQL日期函数日期处理SQL Server

|难度：普通|阅读约 23 分钟

写SQL的人，早晚有一天会被日期函数折磨到怀疑人生。我自己带过不少新人，发现一个规律：select、join、where这些基础语法学得都挺快，一到日期相关的查询就开始各种别扭——要么不知道该用哪个函数，要么算出来的结果差一天，要么明明对着一张日期表却统计不出正确的数据。今天就把我这些年写SQL时常用的日期函数整理一遍，结合SQL Server、MySQL、PostgreSQL这三类主流数据库，把用法、场景、坑都聊透。

这篇内容适合正在学SQL、工作中频繁和日期数据打交道、或者准备SQL面试的朋友阅读。我会按"函数怎么用、什么时候用、容易踩什么坑"的顺序来写，尽量做到看完就能直接上手用。

1. 日期函数为什么是SQL查询的"隐形门槛"

1.1 先搞清楚日期数据的几种存储形态

很多人一上来就记函数名，结果写出来的SQL经常报错或者结果不对，原因往往是没搞懂底层的数据类型。日期在数据库里不是只有一种长相，常用的大概分四类：

date：只存日期，不存时间，格式类似2025-01-15。
time：只存时间，不存日期，类似14:30:00。
datetime / timestamp：日期加时间，类似2025-01-15 14:30:00。
timestamptz / datetimeoffset：带时区的日期时间，类似2025-01-15 14:30:00+08:00。

这个区分为什么重要？因为同一个日期值在不同类型下，比较逻辑和显示结果完全不一样。比如你查"2025-01-15这一天的订单"，如果存储列是datetime类型，那2025-01-15 08:00:00和2025-01-15 23:59:59都属于这一天；如果你直接用等于号写 where order_time = '2025-01-15'，大概率什么都查不到，因为数据库会把'2025-01-15'隐式转成'2025-01-15 00:00:00'，只有正好零点整的订单才匹配得上。

1.2 为什么我建议你养成"日期函数优先"的习惯

早期我见过不少老系统，日期是用varchar存的，比如'2025-01-15'这种字符串。当时这么设计可能是为了方便录入，但后续统计时全是坑：没法直接比较大小，排序会按字典序走，加减天数要自己写逻辑，更别提取星期几或者月末这种操作了。

所以现在但凡新建表，我都强烈建议用数据库原生的日期类型，然后通过日期函数来处理业务逻辑。日期函数不仅是拿来查询的，更是在帮你把"业务时间语义"翻译成数据库能高效执行的条件。比如"最近7天""上个月""年初至今"，这些听起来很简单的话，落到SQL里都需要日期函数来精确表达。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. SQL Server里最常用的日期函数：从GETDATE到EOMONTH

2.1 GETDATE和SYSDATETIME：拿到当前时间只是起点

SQL Server里获取当前时间最基础的就是GETDATE()，它返回datetime类型，精确到毫秒。还有个SYSDATETIME()返回datetime2类型，精度更高，到100纳秒。日常统计场景用GETDATE()足够了。

拿到当前时间之后，常见需求是"取今天零点""取这个月第一天"这类。我见过不少新手写：

sql复制SELECT DATEADD(day, DATEDIFF(day, 0, GETDATE()), 0)

这个写法利用了一个技巧：把日期时间转成距离1900-01-01的天数，再把它加回原点，从而丢掉时间部分。但说实话，这么写太学术了，可读性差。我更喜欢直接用CONVERT配合样式码：

sql复制SELECT CONVERT(date, GETDATE())

把datetime转成date类型，SQL Server会自动截掉时间部分，简洁明了。从SQL Server 2008开始支持这种直接转换，也是我建议优先采用的方式。

2.2 DATEADD和DATEDIFF：日期加减和时间差计算的核心

DATEADD是给日期加上或减去一个时间间隔的，语法是DATEADD(interval, number, date)。interval部分支持year、quarter、month、day、week、hour、minute、second等。

假设订单表Orders里有OrderDate列，我要查"2024年全年订单的预计发货日期各推后3天"：

sql复制SELECT 
    OrderId,
    OrderDate,
    DATEADD(day, 3, OrderDate) AS ExpectedShipDate
FROM Orders
WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01';

DATEDIFF则是计算两个日期之间的间隔数，语法是DATEDIFF(interval, startdate, enddate)。有个特别容易踩的坑：它是用enddate减去startdate，千万别把顺序搞反。而且它是按边界跨越来算的，不是按24小时整段来算。

我举个例子，DATEDIFF(day, '2025-01-01 23:59:59', '2025-01-02 00:00:01')返回1，哪怕实际只隔了2秒，因为日期边界跨了一天。再比如DATEDIFF(year, '2024-12-31', '2025-01-01')返回1，即使只隔1秒。这在计算年龄时特别容易出问题，后面我会专门讲。

2.3 DATEPART和DATENAME：拆解日期元素

有时候你不需要完整的日期，只需要年份、月份、星期几，这时候就用DATEPART或DATENAME。

DATEPART(month, OrderDate)返回月份数字，比如1到12。
DATENAME(month, OrderDate)返回月份名称，比如January。
DATEPART(weekday, OrderDate)返回星期几的数字，但这个受服务器语言和DATEFIRST设置影响，不一定是1到7里你期望的那个1代表周一，所以跨环境要小心。
DATENAME(weekday, OrderDate)返回星期几的名称，比如Monday。

实操中我经常用DATEPART来分组统计。比如按季度统计销售额：

sql复制SELECT 
    DATEPART(year, OrderDate) AS OrderYear,
    DATEPART(quarter, OrderDate) AS OrderQuarter,
    SUM(Amount) AS TotalAmount
FROM Orders
GROUP BY DATEPART(year, OrderDate), DATEPART(quarter, OrderDate)
ORDER BY OrderYear, OrderQuarter;

2.4 EOMONTH：拿月末日期，做账期统计很方便

EOMONTH是SQL Server 2012以后才有的函数，但它太好用了，我必须单独拿出来说。EOMONTH(date)返回指定日期所在月份的最后一天，还支持第二个参数，表示偏移几个月。

拿"上个月最后一天"只需要一句：

sql复制SELECT EOMONTH(GETDATE(), -1);

这个函数在算账期、算月度截止时间时非常省事。没有这个函数的老版本里，要写DATEADD(day, -1, DATEADD(month, DATEDIFF(month, 0, GETDATE()) + 1, 0))，又长又难读。

2.5 FORMAT：格式化日期输出的双刃剑

SQL Server 2012起提供了FORMAT函数，可以用.NET的格式字符串来格式化日期，比如FORMAT(OrderDate, 'yyyy-MM-dd')得到2025-01-15。它的优点是灵活直观，缺点也很致命：性能很差，因为它走的是.NET CLR那一套，数据量大时慢得明显。

我个人的经验是：小数据量、临时查询随便用；大批量报表里，尽量用CONVERT加样式码，比如CONVERT(varchar(10), OrderDate, 120)。120就是ODBC规范的yyyy-mm-dd hh:mi:ss格式，取前10位就是纯日期字符串。

3. MySQL日期函数：做统计报表最顺手的那一批

3.1 NOW、CURDATE和CURTIME：当前时间三兄弟

MySQL里获取当前日期时间用NOW()，它返回datetime类型，包含日期和时间。如果只需要日期，就用CURDATE()；只需要时间，就用CURTIME()。

我写查询时习惯用CURDATE()做默认值。比如查"今天的订单"：

sql复制SELECT *
FROM Orders
WHERE OrderDate >= CURDATE() AND OrderDate < CURDATE() + INTERVAL 1 DAY;

这里用区间而不是等于号，是为了把当天所有时间段的订单都包含进来。INTERVAL 1 DAY这种写法MySQL里到处都用，后面详细说。

3.2 DATE_FORMAT：格式化输出是强项

MySQL的DATE_FORMAT函数非常强大，它用%Y、%m、%d这类占位符来定义输出格式。常见占位符：

%Y：四位年份
%y：两位年份
%m：两位月份
%c：月份数字，不加前导零
%d：两位日期
%H：24小时制小时
%i：分钟
%s：秒
%W：星期名称
%a：星期缩写

我统计某个月每天订单量时经常这么写：

sql复制SELECT 
    DATE_FORMAT(OrderDate, '%Y-%m-%d') AS OrderDay,
    COUNT(*) AS OrderCount
FROM Orders
WHERE OrderDate >= '2025-01-01' AND OrderDate < '2025-02-01'
GROUP BY DATE_FORMAT(OrderDate, '%Y-%m-%d')
ORDER BY OrderDay;

3.3 DATEDIFF和TIMESTAMPDIFF：两个求间隔的函数不要搞混

MySQL里有两个算时间差的函数，很多人容易搞混。

DATEDIFF(date1, date2)只计算天数差，是date1减date2，返回整数。它只关心日期部分，时间部分直接忽略。

TIMESTAMPDIFF(unit, startdate, enddate)则更通用，unit可以指定YEAR、MONTH、DAY、HOUR、MINUTE、SECOND等，是enddate减startdate。

举个例子，我想知道某个用户从注册到现在过了多少个月：

sql复制SELECT 
    UserId,
    TIMESTAMPDIFF(MONTH, RegisterDate, CURDATE()) AS MonthsSinceRegister
FROM Users;

注意两个函数参数顺序是反的：DATEDIFF是大的在前小的在后（date1 - date2），TIMESTAMPDIFF是开始时间在前结束时间在后（end - start）。我吃过好几次亏，建议你用到时顺手注释一下。

3.4 DATE_ADD和DATE_SUB：灵活的日期加减

MySQL里日期加减可以用DATE_ADD(date, INTERVAL expr unit)和DATE_SUB(date, INTERVAL expr unit)，也可以简写成date + INTERVAL expr unit。INTERVAL后面可以跟的数量非常多：DAY、WEEK、MONTH、QUARTER、YEAR、HOUR、MINUTE等。

我想查"最近30天的订单"：

sql复制SELECT *
FROM Orders
WHERE OrderDate >= CURDATE() - INTERVAL 30 DAY;

这样写比写死一个日期字符串要安全得多，因为它会跟着当前日期自动变化。

3.5 LAST_DAY和日期截取函数：处理月度统计有奇效

LAST_DAY(date)是MySQL的月末神器，直接返回该月最后一天。配合DATE_ADD可以做很多事：

sql复制-- 获取上个月最后一天
SELECT LAST_DAY(CURDATE() - INTERVAL 1 MONTH);

-- 获取这个月第一天
SELECT DATE_ADD(LAST_DAY(CURDATE() - INTERVAL 1 MONTH), INTERVAL 1 DAY);

MySQL还提供了YEAR(date)、MONTH(date)、DAY(date)、HOUR(date)等快捷函数，可以直接从日期里取出对应的部分。WHERE YEAR(OrderDate) = 2025这种写法确实直观，但要注意它可能导致索引失效，后面讲踩坑时细说。

4. PostgreSQL日期函数：算时间差和日期截断最舒服

4.1 CURRENT_DATE和CURRENT_TIMESTAMP：标准SQL风格

PostgreSQL里取当前日期用CURRENT_DATE，当前时间用CURRENT_TIMESTAMP，也可以写NOW()。CURRENT_DATE和CURRENT_TIMESTAMP是标准SQL语法，所以跨数据库时兼容性更好。

PostgreSQL的时间精度默认到微秒，比SQL Server和MySQL都细。如果你只要日期部分，直接写CURRENT_DATE即可，不需要再做转换。

4.2 EXTRACT：从时间戳里抽字段

PostgreSQL的EXTRACT(field FROM source)用于从日期时间中提取字段，field支持YEAR、MONTH、DAY、HOUR、MINUTE、SECOND、DOW（一周中的第几天，周日为0）、DOY（一年中的第几天）、WEEK等。

举例，按月和星期几分组统计流量：

sql复制SELECT 
    EXTRACT(MONTH FROM AccessTime) AS AccessMonth,
    EXTRACT(DOW FROM AccessTime) AS AccessWeekday,
    COUNT(*) AS AccessCount
FROM AccessLog
WHERE AccessTime >= CURRENT_DATE - INTERVAL '3 months'
GROUP BY EXTRACT(MONTH FROM AccessTime), EXTRACT(DOW FROM AccessTime)
ORDER BY AccessMonth, AccessWeekday;

DOW返回的是0到6，0对应周日。如果你希望周一对应1，需要自己加处理：(EXTRACT(DOW FROM AccessTime) + 6) % 7 + 1。这里没有直接可用的ISODOW是因为整体语义稍复杂，我一般直接用ISODOW，它符合ISO标准，周一为1周日为7，更符合国内习惯。

4.3 DATE_TRUNC：按周月年做时间截断，报表必备

DATE_TRUNC是PostgreSQL里我觉得最优雅的函数，没有之一。它把日期时间截断到指定精度，比如month级别，会把结果归到这个月的第一天零点。

sql复制SELECT DATE_TRUNC('month', CURRENT_DATE);

返回的是2025-01-01 00:00:00。这在分组统计时非常好用，因为可以直接用它做GROUP BY的键，而不是分别取年份和月份：

sql复制SELECT 
    DATE_TRUNC('month', OrderDate) AS OrderMonth,
    SUM(Amount) AS TotalAmount
FROM Orders
WHERE OrderDate >= DATE_TRUNC('year', CURRENT_DATE)
GROUP BY DATE_TRUNC('month', OrderDate)
ORDER BY OrderMonth;

DATE_TRUNC支持的年月日周时分级精度都有，比如day截到当天零点，hour截到小时整点。对于生成连续时间序列或者做趋势分析很有价值。

4.4 AGE：专门算年龄和时长的函数

PostgreSQL的AGE(enddate, startdate)返回的是interval类型，直接给出"x年x月x日"这样的描述。比如：

sql复制SELECT AGE(CURRENT_DATE, BirthDate) FROM Users;

返回类似"28 years 3 mons 10 days"的interval。如果你只需要年份数字，可以配合EXTRACT：

sql复制SELECT EXTRACT(YEAR FROM AGE(CURRENT_DATE, BirthDate)) FROM Users;

这个在算年龄时比自己去DATEDIFF要准得多，因为AGE是按日历上的年月日差来算的，而不是简单地用天数除365。

4.5 TO_CHAR：格式化日期最灵活

PostgreSQL的TO_CHAR类似MySQL的DATE_FORMAT，用模板模式输出。用法是TO_CHAR(date, 'YYYY-MM-DD')，支持的模式非常丰富，比如'YYYY"年"MM"月"DD"日"'可以直接输出中文格式。

需要注意PostgreSQL的模式串里，分钟是MI而不是MM，小时是HH24表示24小时制。如果你拿MySQL的习惯直接套，很容易把分钟写成MM，结果输出的不是预想的分钟数。

5. 跨数据库通用日期处理思路：不管什么库都能套

5.1 日期比较的通用规则

不管用哪个数据库，日期比较有一条通用规则：用范围查询，不要用等于查询。查某一天的数据，写成：

sql复制WHERE OrderDate >= '2025-01-15' AND OrderDate < '2025-01-16'

而不是：

sql复制WHERE OrderDate = '2025-01-15'

前者无论OrderDate列是date还是datetime类型都能准确命中。这个习惯在MySQL、SQL Server、PostgreSQL里全部适用，甚至Oracle也一样。

5.2 用标准SQL函数提高可移植性

如果你在多个数据库之间切换，尽量用那些属于SQL标准的函数。比如CURRENT_DATE、CURRENT_TIMESTAMP、EXTRACT这些，在主流数据库里都有支持，只是细节略有差异。而FORMAT（SQL Server）、DATE_FORMAT（MySQL）、TO_CHAR（PostgreSQL）这类函数则完全是各家私有语法，一旦换库就要重写。

我自己的原则是：逻辑查询尽量用标准语法，只有报表格式化输出才用各家特色函数。这样万一以后换数据库，改动成本会小很多。

5.3 在应用层处理时区，还是在SQL层处理

时区是日期处理的大坑。很多团队的做法是数据库统一存UTC时间，应用层展示时再转本地时间。这时候查询条件里如果直接用CURRENT_DATE，拿到的是数据库服务器的本地日期，如果服务器时区设置不对，统计就会偏差。

我建议的做法是：在应用层把需要查询的时间范围算好，作为参数传给SQL，而不是在SQL里调用当前日期函数。这样既能保证时区正确，也方便代码复用和测试。SQL里尽量只做已确定时间区间的过滤和分组。

6. 实战场景：报表统计里那些绕不开的日期计算

6.1 按天、按月、按年分组统计

分组统计是最常见的日期处理场景。核心思路是先把日期截断到需要的粒度，再分组。不同数据库的截断方式不一样：

SQL Server：用CONVERT(date, OrderDate)或FORMAT
MySQL：用DATE(OrderDate)或DATE_FORMAT(OrderDate, '%Y-%m-01')做月份
PostgreSQL：用DATE_TRUNC('day', OrderDate)或DATE_TRUNC('month', OrderDate)

按月统计销售额：

sql复制-- SQL Server
SELECT 
    CONVERT(char(7), OrderDate, 120) AS OrderMonth,
    SUM(Amount) AS TotalAmount
FROM Orders
GROUP BY CONVERT(char(7), OrderDate, 120)
ORDER BY OrderMonth;

-- MySQL
SELECT 
    DATE_FORMAT(OrderDate, '%Y-%m') AS OrderMonth,
    SUM(Amount) AS TotalAmount
FROM Orders
GROUP BY DATE_FORMAT(OrderDate, '%Y-%m')
ORDER BY OrderMonth;

-- PostgreSQL
SELECT 
    TO_CHAR(DATE_TRUNC('month', OrderDate), 'YYYY-MM') AS OrderMonth,
    SUM(Amount) AS TotalAmount
FROM Orders
GROUP BY DATE_TRUNC('month', OrderDate)
ORDER BY OrderMonth;

6.2 环比和同比：和上一个周期比

统计报表里经常要算环比、同比。所谓环比就是和上一个统计周期比，同比就是和去年同周期比。

看"本月销售额对比上月"：

sql复制-- SQL Server
SELECT
    DATEADD(month, -1, GETDATE()) AS LastMonthDate;

-- MySQL
SELECT CURDATE() - INTERVAL 1 MONTH;

-- PostgreSQL
SELECT CURRENT_DATE - INTERVAL '1 month';

实际报表里常见的做法是先把本月和上月的汇总分别查出来，再JOIN在一起对比。比如：

sql复制WITH current_month AS (
    SELECT SUM(Amount) AS Amount
    FROM Orders
    WHERE OrderDate >= '2025-01-01' AND OrderDate < '2025-02-01'
),
previous_month AS (
    SELECT SUM(Amount) AS Amount
    FROM Orders
    WHERE OrderDate >= '2024-12-01' AND OrderDate < '2025-01-01'
)
SELECT
    current_month.Amount AS CurrentAmount,
    previous_month.Amount AS PreviousAmount,
    (current_month.Amount - previous_month.Amount) / previous_month.Amount * 100 AS GrowthRate
FROM current_month, previous_month;

这里需要注意的是月份边界条件，必须写成大于等于月初且小于下月月初，不能写小于等于月末，否则会漏掉月末那天的数据（如果时间部分是00:00之后的话）。

6.3 年龄计算：DATEDIFF直接减年份不够准

年龄是最典型的"看起来简单，实际有坑"的日期计算。很多人直接拿当前年份减出生年份：

sql复制SELECT YEAR(GETDATE()) - YEAR(BirthDate) AS Age FROM Users;

这个写法在还没过生日时就会大一岁。比如2025年1月15日，一个人2000年12月出生，按这个算已经25岁了，但人家其实才24岁。

更准确的做法是判断今年生日过没过：

sql复制SELECT 
    DATEDIFF(year, BirthDate, GETDATE()) - 
    CASE 
        WHEN DATEADD(year, DATEDIFF(year, BirthDate, GETDATE()), BirthDate) > GETDATE() 
        THEN 1 ELSE 0 
    END AS Age
FROM Users;

PostgreSQL用AGE函数就省心很多：

sql复制SELECT EXTRACT(YEAR FROM AGE(CURRENT_DATE, BirthDate)) AS Age FROM Users;

6.4 最近7天、本月至今、年初至今的通用写法

这些时间窗口在报表里出现频率极高，我整理了三个常用口径的写法：

最近7天：WHERE OrderDate >= CURDATE() - INTERVAL 7 DAY
本月至今：WHERE OrderDate >= DATE_TRUNC('month', CURRENT_DATE)
年初至今：WHERE OrderDate >= DATE_TRUNC('year', CURRENT_DATE)

SQL Server则对应写成：

sql复制-- 最近7天
WHERE OrderDate >= DATEADD(day, -7, GETDATE())

-- 本月至今
WHERE OrderDate >= DATEFROMPARTS(YEAR(GETDATE()), MONTH(GETDATE()), 1)

-- 年初至今
WHERE OrderDate >= DATEFROMPARTS(YEAR(GETDATE()), 1, 1)

这里推荐SQL Server用DATEFROMPARTS来构造日期，可读性比DATEADD套DATEDIFF好太多。DATEFROMPARTS(2025, 1, 1)直接得到2025-01-01，一看就明白。

7. 日期查询容易踩的坑：我是怎么排查和解决的

7.1 函数套在列上，导致索引失效

这是性能问题里最常见的一种。举个例子，用户表有十万行，我在BirthDate列上建了索引，想查1月出生的用户：

sql复制SELECT * FROM Users WHERE MONTH(BirthDate) = 1;

这句话逻辑没错，但它对每一行的BirthDate都执行了一次MONTH函数，导致索引完全用不上，只能全表扫描。数据量一大就卡。

改进方式是把它改写成范围条件：

sql复制SELECT * FROM Users 
WHERE BirthDate >= '2025-01-01' AND BirthDate < '2025-02-01';

这个写法完全不需要在列上做函数运算，索引能正常使用。这也是为什么我一直强调：能用范围表示的条件，就尽量不要用函数。

7.2 用字符串比较日期，格式统一才能命中

有的系统日期列是varchar的，比如存'2025-1-5'这种不太规整的格式，你在SQL里写WHERE OrderDate >= '2025-01-01'，结果可能对不上，因为字符串比较是一位一位比的，'2025-1-5'和'2025-01-01'在第七个字符就分出高下了。

处理办法是：要么查的时候把字符串转成日期类型，要么在建表时就规范成统一格式。我会优先选择把存储层改成date类型，因为字符串存日期带来的问题远不止比较这一个。

7.3 BETWEEN AND的边界问题：含头不含尾

BETWEEN AND在SQL里是闭区间，也就是包含两端。当你查某一天的数据时，BETWEEN '2025-01-15' AND '2025-01-15'在date类型下没问题，但在datetime类型下，等于只查到了'2025-01-15 00:00:00'这一瞬间的记录，后面的全部丢了。

所以我很少在日期查询里用BETWEEN，而是用大于等于加小于的组合。原因就是闭区间在datetime下太容易踩边界坑。你永远不知道哪天的数据会带着时间部分，干脆用半开区间一劳永逸。

7.4 时区字段被忽略，统计结果差8小时

如果你在跨国业务或者云数据库上工作，一定要留意时区。PostgreSQL的timestamptz类型会自动做时区转换，而timestamp不会。MySQL的TIMESTAMP类型会根据会话时区转换，DATETIME则不会。

我曾经排查过一个线上问题：报表显示当天订单为0，实际订单很多。最后定位到是数据库连接串里的时区参数和服务器时区不一致，查询条件里用了本地日期的字符串，和数据库存的UTC时间一比，自然错位了。建议在连接串里显式指定时区，并统一所有环境的时间口径。

7.5 闰年和月末日期的特殊处理

日期计算最容易出问题的还有闰年。比如要算"去年的今天"，有人直接写DATEADD(year, -1, GETDATE())，这在2月29日会出问题：2024年是闰年，2025年没有2月29日，数据库会怎么处理？SQL Server会返回2025-02-28，MySQL也会返回2025-02-28，PostgreSQL的interval计算同样会归一化到2月28日。大部分数据库都做了兼容处理，但如果你自己用字符串拼接日期，那就可能生成一个不存在的日期。

月末计算也是同理。想取某个月的最后一天，用EOMONTH或LAST_DAY是靠谱的，千万别自己写"下月1号减1天"以外的算法，尤其在2月这种特殊月份上容易翻车。

8. 结尾：我的日期函数使用习惯

最后分享几点我个人总结的习惯。第一，凡是日期查询，先确认列的类型是date还是datetime，再决定用等于号还是范围；第二，能用半开区间就别用BETWEEN，能用范围就别在列上套函数；第三，分组统计优先用DATE_TRUNC这类截断函数，而不是分别取年、月再拼接字符串；第四，跨系统传日期时统一用'YYYY-MM-DD'格式的字符串或ISO标准格式，减少隐式转换带来的意外。

日期函数本身不难，难的是把边界、时区、类型这些细节都考虑到。你只要多写几次真实报表，踩过几次坑，自然就记住了。希望这篇整理能让你少走点弯路。