SQL日期函数详解：从基础使用到高级技巧

1. 为什么SQL日期函数如此重要

在日常数据处理工作中，我经常遇到这样的场景：市场部门需要上个月同期的销售对比报表，财务系统要求生成季度汇总数据，用户行为分析需要按周统计活跃度。这些需求的核心都指向同一个技术点——日期处理。根据我多年的数据库开发经验，约60%的业务查询都涉及日期计算，而90%的初级SQL错误都发生在日期函数使用不当上。

日期函数就像SQL工具箱里的瑞士军刀，看起来简单但功能强大。上周我就帮团队解决了一个典型问题：新同事写的月度报表查询，在2月28日运行时竟然漏掉了最后三天的数据。原因是他直接用MONTH(CURRENT_DATE) - 1获取上个月，而没考虑跨年情况。这个案例让我意识到，系统掌握日期函数不仅能提高效率，更能避免隐蔽的逻辑错误。

2. 基础日期函数详解

2.1 获取当前日期与时间

最基础的三个函数是每个SQL开发者必须熟悉的：

sql复制SELECT 
    CURRENT_DATE AS 当前日期,  -- 2023-11-20
    CURRENT_TIMESTAMP AS 当前时间戳,  -- 2023-11-20 14:30:45.123
    LOCALTIMESTAMP AS 本地时间戳  -- 不带时区

这里有个容易忽略的细节：不同数据库的实现差异。MySQL中NOW()和SYSDATE()看起来相同，但SYSDATE()每次调用都获取实时系统时间，而NOW()在语句开始时确定后保持不变。在Oracle中则需要用SYSDATE，PostgreSQL则支持CURRENT_TIMESTAMP和transaction_timestamp()。

提示：生产环境中要特别注意时区问题。我曾遇到过一个报表在测试环境正常，上线后时间差8小时的情况。解决方案是统一使用AT TIME ZONE 'UTC'或配置数据库会话时区。

2.2 日期提取与格式化

提取日期部分最常用的函数族：

sql复制-- 提取年/月/日
SELECT 
    EXTRACT(YEAR FROM order_date) AS 订单年份,
    DATE_PART('month', payment_time) AS 支付月份,  -- PostgreSQL语法
    DAY(create_time) AS 创建日  -- MySQL语法
FROM orders;

-- 格式化输出
SELECT 
    TO_CHAR(ship_date, 'YYYY-MM-DD') AS 标准日期,  -- Oracle/PostgreSQL
    DATE_FORMAT(delivery_time, '%W %M %Y') AS 完整日期  -- MySQL: Tuesday November 2023

这里有个实用技巧：当需要按周分析数据时，EXTRACT(WEEK FROM date)在不同数据库中的周起始日可能不同。在MySQL中可以用WEEK(date, mode)指定模式，比如mode=3表示ISO标准周（周一作为周起始）。

3. 日期计算与区间处理

3.1 日期加减运算

处理时间间隔的三种典型方式：

sql复制-- MySQL
SELECT 
    DATE_ADD(start_date, INTERVAL 7 DAY) AS 一周后,
    DATE_SUB(end_date, INTERVAL 3 MONTH) AS 三个月前;

-- PostgreSQL
SELECT 
    hire_date + INTERVAL '1 year' AS 转正日期,
    expire_time - INTERVAL '30 minutes' AS 提前半小时;

-- SQL Server
SELECT 
    DATEADD(DAY, -15, due_date) AS 提前两周,
    DATEDIFF(HOUR, start_time, end_time) AS 耗时小时数

实际项目中我总结出一个经验：处理月末日期时要特别小心。比如计算"下个月今天"，直接用+1 MONTH在1月31日会得到2月28日（非闰年），这可能不符合业务预期。保险的做法是先用LAST_DAY(date)获取月末，再进行计算。

3.2 日期差计算

计算两个日期间隔的常见需求：

sql复制-- 跨数据库通用方案
SELECT 
    end_date - start_date AS 天数差,  -- 多数数据库支持
    DATEDIFF(DAY, begin_time, end_time) AS 精确天数,  -- SQL Server
    AGE(complete_time, create_time) AS 间隔详情  -- PostgreSQL: 3 days 02:15:00

在电商项目中，我设计过一个计算用户回购周期的查询：

sql复制SELECT 
    customer_id,
    AVG(DATEDIFF(DAY, prev_order, order_date)) AS 平均回购周期
FROM (
    SELECT 
        customer_id,
        order_date,
        LAG(order_date) OVER (PARTITION BY customer_id ORDER BY order_date) AS prev_order
    FROM orders
) t
WHERE prev_order IS NOT NULL
GROUP BY customer_id;

这个查询使用了窗口函数配合日期计算，能准确反映用户消费习惯。

4. 高级日期处理技巧

4.1 工作日计算

金融行业经常需要排除节假日的计算，这里分享我的实现方案：

sql复制-- 创建日历表
CREATE TABLE calendar (
    date DATE PRIMARY KEY,
    is_workday BOOLEAN,
    holiday_name VARCHAR(50)
);

-- 工作日计算查询
SELECT 
    COUNT(*) AS workdays
FROM calendar
WHERE date BETWEEN '2023-11-01' AND '2023-11-30'
AND is_workday = TRUE
AND EXTRACT(DOW FROM date) NOT IN (0, 6);  -- 排除周末

更复杂的场景可以使用递归CTE生成日期序列：

sql复制WITH RECURSIVE date_range AS (
    SELECT '2023-01-01'::DATE AS date
    UNION ALL
    SELECT date + 1
    FROM date_range
    WHERE date < '2023-12-31'
)
SELECT date 
FROM date_range
WHERE EXTRACT(DOW FROM date) BETWEEN 1 AND 5;  -- 1-5表示周一到周五

4.2 时区转换实战

跨国业务必须处理的时区问题：

sql复制-- PostgreSQL示例
SELECT 
    create_time AT TIME ZONE 'UTC' AT TIME ZONE 'America/New_York' AS ny_time,
    create_time AT TIME ZONE 'Asia/Shanghai' AS local_time
FROM events;

-- MySQL 8.0+
SELECT 
    CONVERT_TZ(transaction_time, '+00:00', '+08:00') AS beijing_time
FROM payments;

我曾参与过一个全球日志分析系统建设，时区问题导致的时间对齐错误让团队花了三天排查。最终方案是在数据库层面统一存储UTC时间，只在展示层做转换。

5. 常见陷阱与性能优化

5.1 日期函数索引失效

这是最容易被忽视的性能问题。比如以下查询在MySQL中无法使用索引：

sql复制-- 反例：索引失效
SELECT * FROM orders 
WHERE YEAR(order_date) = 2023 AND MONTH(order_date) = 11;

-- 正例：可走索引
SELECT * FROM orders 
WHERE order_date BETWEEN '2023-11-01' AND '2023-11-30';

在Oracle中，对日期列使用TO_CHAR函数也会导致索引失效。解决方案是使用函数索引：

sql复制CREATE INDEX idx_orders_ym ON orders(TO_CHAR(order_date, 'YYYY-MM'));

5.2 边界条件处理

日期查询中最容易出错的边界情况：

sql复制-- 错误做法：可能漏掉23:59:59的数据
SELECT * FROM logs 
WHERE create_date BETWEEN '2023-11-01' AND '2023-11-30';

-- 正确做法：包含完整最后一天
SELECT * FROM logs 
WHERE create_date >= '2023-11-01' 
AND create_date < '2023-12-01';

在银行项目中，我曾见过一个日终跑批作业因为BETWEEN的边界问题，导致当日最后几分钟的交易被漏处理，造成对账不平。从此我们团队约定：所有日期范围查询必须使用>=和<组合。

6. 数据库特定函数对比

6.1 主流数据库日期函数差异

通过表格对比不同数据库的日期函数实现：

6.2 跨数据库兼容方案

对于需要支持多数据库的应用，我推荐以下策略：

1. 使用标准SQL语法：如CURRENT_DATE、EXTRACT
2. 在应用层实现日期计算
3. 使用数据库抽象层或ORM工具的函数转换

例如，计算两个日期间的工作日数可以封装为存储过程：

sql复制-- MySQL示例
CREATE FUNCTION workdays_between(start_date DATE, end_date DATE) 
RETURNS INT
BEGIN
    DECLARE days INT DEFAULT 0;
    DECLARE d DATE DEFAULT start_date;
    
    WHILE d <= end_date DO
        IF DAYOFWEEK(d) NOT IN (1,7) THEN
            SET days = days + 1;
        END IF;
        SET d = DATE_ADD(d, INTERVAL 1 DAY);
    END WHILE;
    
    RETURN days;
END;

7. 真实业务场景应用

7.1 零售业销售周期分析

连锁超市的周同比分析查询：

sql复制WITH current_week AS (
    SELECT 
        product_id,
        SUM(amount) AS current_sales
    FROM sales
    WHERE sale_date BETWEEN CURRENT_DATE - INTERVAL '7 days' AND CURRENT_DATE
    GROUP BY product_id
),
last_week AS (
    SELECT 
        product_id,
        SUM(amount) AS last_sales
    FROM sales
    WHERE sale_date BETWEEN CURRENT_DATE - INTERVAL '14 days' AND CURRENT_DATE - INTERVAL '7 days'
    GROUP BY product_id
)
SELECT 
    p.product_name,
    c.current_sales,
    l.last_sales,
    ROUND((c.current_sales - l.last_sales) / l.last_sales * 100, 2) AS growth_rate
FROM current_week c
JOIN last_week l ON c.product_id = l.product_id
JOIN products p ON c.product_id = p.product_id
ORDER BY growth_rate DESC;

这个查询使用了日期区间计算配合CTE，能清晰展示商品销售趋势变化。

7.2 用户留存率计算

互联网产品的经典留存分析：

sql复制SELECT 
    first_day,
    COUNT(DISTINCT user_id) AS new_users,
    COUNT(DISTINCT CASE WHEN activity_date = first_day + INTERVAL '1 day' THEN user_id END) / 
        COUNT(DISTINCT user_id)::FLOAT AS day1_retention,
    COUNT(DISTINCT CASE WHEN activity_date BETWEEN first_day + INTERVAL '7 day' AND first_day + INTERVAL '13 day' THEN user_id END) / 
        COUNT(DISTINCT user_id)::FLOAT AS week2_retention
FROM (
    SELECT 
        user_id,
        DATE(MIN(login_time)) AS first_day
    FROM user_activities
    GROUP BY user_id
) cohorts
JOIN user_activities ON user_activities.user_id = cohorts.user_id
WHERE activity_date <= first_day + INTERVAL '13 day'
GROUP BY first_day
ORDER BY first_day;

这个查询通过日期函数计算用户生命周期关键节点，是增长分析的核心工具。