数据库日期函数实战指南：格式化、计算与索引优化

1. 从一次慢查询说起：日期函数真的会用吗

几个月前帮一个同事排查报表接口的慢查询，SQL本身逻辑不复杂，就是查最近三十天的订单数据，但每次执行都要三秒多。我一眼扫过去就看到了问题：WHERE DATE(create_time) = CURDATE()。这写法逻辑上没错，但DATE()函数包在索引列上，索引直接失效，全表扫描跑不掉。

这种问题在写SQL时太常见了。日期函数看起来简单，每个人都会写几个，但真正能写出高效、可维护、跨数据库兼容的日期查询，其实藏着不少门道。尤其是面试的时候，十个SQL题里至少有四个会跟日期打交道。

这篇文章把我这些年实际踩过的坑、总结过的写法一次性聊透。我会按照日期函数的实际用途来拆解，覆盖MySQL、SQL Server、Oracle、PostgreSQL这几个主流数据库，重点讲清楚每个函数背后的逻辑和适用场景，而不是单纯罗列函数列表。不管你是在校学生准备面试，还是工作了三五年的开发想补一补基础，这篇文章都值得花十分钟读完。

2. 日期函数到底在解决什么问题

2.1 先搞清楚数据库里的日期是怎么存的

理解日期函数之前，必须先理解日期在数据库里的存储方式。这就像你要学会切菜，总得先知道刀放在哪。

MySQL的DATETIME类型存储格式是YYYY-MM-DD HH:MM:SS，占用8字节；DATE只存日期部分，占用3字节；TIMESTAMP也是8字节，但范围只有1970年到2038年，而且会自动跟随时区变化。SQL Server的DATETIME精度到3.33毫秒，而DATETIME2精度更高，范围更大。Oracle的DATE类型其实包含时间部分，精确到秒。PostgreSQL则把日期和时间拆得更细，有DATE、TIME、TIMESTAMP、TIMESTAMPTZ等多种类型。

这些差异直接决定了你写的函数在不同数据库里能不能跑通。比如MySQL的NOW()和SYSDATE()两个函数，看起来都是返回当前时间，但NOW()是语句开始执行的时间点，SYSDATE()是函数被调用的那一刻。一条SQL里如果SYSDATE()用了多次，返回的秒数可能都不一样。

2.2 日期函数的四大核心场景

我在实际工作中，把日期函数的使用场景归纳为四类：

格式化与解析：把日期转成指定格式的字符串，或者把字符串解析成日期。这是最基础的操作，报表导出、日志分析、接口对接都会用到。

日期计算：对日期进行加减运算，比如往前推七天、往后推一个月、计算两个日期之间相差多少天。业务上的“最近N天”“本月至今”“去年同期”全是这类需求。

日期截断与提取：提取日期的年、月、日、季度、星期几等部分，或者把时间归零只保留日期。这主要用于分组统计，比如按天、按月聚合数据。

日期比较与条件筛选：在WHERE条件中根据日期范围过滤数据。这是最能体现功力的地方，写得好不好直接决定查询性能。

理解这四类场景后，你去学习具体函数时就有了框架，不会杂乱无章。

3. 格式化与解析：最容易出幺蛾子的环节

3.1 MySQL的DATE_FORMAT与STR_TO_DATE

MySQL里最常用的格式化函数是DATE_FORMAT(date, format)，它把日期值按照指定格式转成字符串。格式符是大小写敏感的，这一点很多人会忽略：

sql复制-- 格式符区分大小写，这是很多新手踩坑的地方
SELECT DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:%s');
-- 结果: 2024-11-25 14:30:45

SELECT DATE_FORMAT(NOW(), '%y-%m-%d %h:%i:%s %p');
-- 结果: 24-11-25 02:30:45 PM

注意%Y是四位的年份，%y是两位的；%H是24小时制，%h是12小时制。如果你做报表时发现时间总差12小时，多半是%H被写成了%h。

反向解析用STR_TO_DATE(str, format)，把字符串变成日期：

sql复制-- 把客户端传来的字符串转成日期进行范围查询
SELECT STR_TO_DATE('2024-11-25 14:30:45', '%Y-%m-%d %H:%i:%s');

实操心得：接口对接时，前端传过来的日期往往是字符串，直接拿去和DATETIME列比较，MySQL会做隐式转换。这个转换有时成功有时失败，全看字符串格式。我见过不少线上故障，就是因为前端传了个2024/11/25这种格式，MySQL死活转不出正确的日期。稳妥的做法是在应用层做好格式校验，SQL里显式用STR_TO_DATE转换，不要依赖隐式转换。

3.2 SQL Server的CONVERT与FORMAT

SQL Server里日期格式化用CONVERT(varchar, date, style)，第三个参数是样式代码，这是SQL Server特有的用法：

sql复制-- 样式代码 120 对应 ODBC 标准的 yyyy-mm-dd hh:mi:ss
SELECT CONVERT(VARCHAR(19), GETDATE(), 120);
-- 结果: 2024-11-25 14:30:45

-- 样式代码 112 对应 yyyymmdd，适合做文件名
SELECT CONVERT(VARCHAR(8), GETDATE(), 112);
-- 结果: 20241125

常用的样式代码就那么几个：120是标准时间格式，112是纯日期无分隔符，101是美式MM/DD/YYYY，23是YYYY-MM-DD。记不住也没关系，用的时候查一下，用得多了自然就记住了。

SQL Server 2012之后提供了FORMAT函数，用法跟其他语言的格式化习惯一致：

sql复制SELECT FORMAT(GETDATE(), 'yyyy-MM-dd HH:mm:ss');

但FORMAT的性能比CONVERT差很多，因为它走的是.NET的格式化管道。数据量大的查询里不要用，否则性能会很感人。

3.3 Oracle与PostgreSQL的格式化

Oracle里是TO_CHAR和TO_DATE，格式符跟MySQL不太一样，但逻辑类似：

sql复制SELECT TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') FROM DUAL;
SELECT TO_DATE('2024-11-25', 'YYYY-MM-DD') FROM DUAL;

注意Oracle里MI表示分钟，MM表示月，HH24表示24小时制。如果你写成HH，默认是12小时制，就会出现凌晨和下午混淆的问题。

PostgreSQL里是TO_CHAR和TO_TIMESTAMP：

sql复制SELECT TO_CHAR(NOW(), 'YYYY-MM-DD HH24:MI:SS');
SELECT TO_TIMESTAMP('2024-11-25 14:30:45', 'YYYY-MM-DD HH24:MI:SS');

PostgreSQL的TO_TIMESTAMP返回的是带时区的TIMESTAMPTZ类型，如果只想解析成不带时区的TIMESTAMP，需要用CAST或::timestamp。

避坑提醒：格式化函数是最容易出问题的，因为不同数据库的格式符体系不一样。你在一套数据库里写习惯的格式，换到另一套数据库完全不认。我自己维护过多套数据库的代码，最稳妥的做法是：日期格式转换尽量在应用层做，SQL只负责取原始值。如果必须在SQL里做，那就写适配当前数据库的方言，不要写一套SQL到处跑。

4. 日期计算：加减运算与区间推算

4.1 MySQL的DATE_ADD、DATE_SUB与INTERVAL

日期加减是业务需求里最频繁的操作，比如“查最近七天的数据”“查上个月的数据”。MySQL的写法是DATE_ADD(date, INTERVAL expr unit)和DATE_SUB(date, INTERVAL expr unit)：

sql复制-- 七天前
SELECT DATE_SUB(CURDATE(), INTERVAL 7 DAY);
-- 一个月后
SELECT DATE_ADD(CURDATE(), INTERVAL 1 MONTH);
-- 这个写法更推荐，语义清晰
SELECT CURDATE() + INTERVAL 1 DAY;

INTERVAL的单位非常多，DAY、WEEK、MONTH、QUARTER、YEAR，还有组合单位DAY_HOUR、YEAR_MONTH。实际操作中常用的是单个单位，组合单位用得少。

一个容易搞混的点：DATE_ADD和DATE_SUB虽然名字不同，但你完全可以用DATE_ADD加减法，只要INTERVAL前用负数就行：

sql复制-- 这两种写法结果一样
SELECT DATE_SUB(CURDATE(), INTERVAL 1 DAY);
SELECT DATE_ADD(CURDATE(), INTERVAL -1 DAY);

我个人的习惯是统一用DATE_ADD配合正负号，这样代码里加减操作一眼就能识别。

4.2 SQL Server的DATEADD与DATEDIFF

SQL Server的DATEADD和DATE_SUB类似，但写法更简洁：

sql复制SELECT DATEADD(DAY, -7, GETDATE());
SELECT DATEADD(MONTH, 1, GETDATE());

DATEADD的第一个参数是时间单位，第二个参数是增量（可正可负），第三个是基准日期。时间单位用DAY、MONTH、YEAR、HOUR、MINUTE等，没有MySQL那么多花活。

SQL Server里计算两个日期相差多少天用DATEDIFF：

sql复制-- 两个日期相差的天数
SELECT DATEDIFF(DAY, '2024-01-01', '2024-11-25');
-- 结果: 329

这里容易搞错的是参数顺序。DATEDIFF(unit, start_date, end_date)返回的是end_date - start_date，不要写反了。我见过有人为了试这个顺序，来回改了好几次。

4.3 Oracle的日期直接加减

Oracle的日期加减是这些数据库里最直观的，日期直接加数字，单位是天：

sql复制-- 七天前
SELECT SYSDATE - 7 FROM DUAL;
-- 一个月后（注意ADD_MONTHS是专门函数）
SELECT ADD_MONTHS(SYSDATE, 1) FROM DUAL;
-- 两个日期相差天数
SELECT SYSDATE - DATE'2024-01-01' FROM DUAL;

Oracle里DATE类型可以直接做算术运算，SYSDATE + 1就是明天同一时刻。但加一个月就不能直接+30，因为月份天数的差异，所以Oracle专门提供了ADD_MONTHS函数。这也提醒我们，在做跨月的日期计算时，不同数据库的语义可能有细微差别。

PostgreSQL的日期加减跟Oracle类似：

sql复制SELECT NOW() - INTERVAL '7 days';
SELECT DATE '2024-01-01' + 7;  -- 日期加整数是天，返回日期
SELECT DATE '2024-11-25' - DATE '2024-01-01';  -- 返回天数

4.4 日期计算里的边界问题

日期计算看着简单，但“一个月”到底是多少天，不同数据库有自己的规则。MySQL的DATE_ADD('2024-01-31', INTERVAL 1 MONTH)返回的是2024-02-29，如果你的系统把结果用于业务判断，这个差异就可能引发问题。

比如会员有效期、账期计算这类场景，如果用户1月31日开通月卡，有效期应该到2月28日还是3月2日？不同业务有不同想法，你需要明确业务规则后再选择合适的函数。这个一定要在产品层面想清楚，不能寄希望于数据库函数帮你自动处理。

我习惯的做法是：涉及跨月计算的业务，先在测试环境把边界场景跑一遍，比如1月31日加一个月、2月29日加一年、12月31日加一个月这些情况，确认结果符合业务预期再上线。

5. 日期截断与提取：分组统计的基石

5.1 MySQL的DATE、YEAR、MONTH、DAY等提取函数

按天、按月、按年分组统计，是报表系统里最典型的场景。MySQL提供了一组提取函数：

sql复制SELECT 
    YEAR(create_time) AS y,
    MONTH(create_time) AS m,
    DAY(create_time) AS d,
    QUARTER(create_time) AS q,
    WEEK(create_time, 1) AS w,  -- 第二个参数1表示周一为一周开始
    WEEKDAY(create_time) AS wd  -- 0=周一, 6=周日
FROM orders
ORDER BY y, m, d;

还有一个高频操作是“去掉时间部分，只保留日期”。常规做法是DATE(create_time)，但这会破坏索引。更优的写法是用范围查询，这个放到后面性能优化部分细说。

MySQL里还有个冷门但好用的函数EXTRACT，它可以从日期提取指定部分：

sql复制SELECT EXTRACT(YEAR_MONTH FROM create_time) AS ym FROM orders;
-- 结果类似 202411，按月份分组的利器

5.2 SQL Server的DATEPART与DATENAME

SQL Server用DATEPART提取日期部分，返回的是整数；DATENAME返回的是字符串名称：

sql复制SELECT 
    DATEPART(YEAR, create_time) AS y,
    DATEPART(MONTH, create_time) AS m,
    DATEPART(DAY, create_time) AS d,
    DATEPART(WEEKDAY, create_time) AS wd,  -- 1=周日, 7=周六
    DATENAME(MONTH, create_time) AS month_name  -- 返回'November'
FROM orders;

坑点：SQL Server的DATEPART(WEEKDAY, ...)返回的1是周日，7是周六，跟中国的习惯不一样。如果你要按周一为一周的开始来做统计，需要调整：

sql复制-- 把周一调整为1
SELECT (DATEPART(WEEKDAY, create_time) + 5) % 7 + 1 AS wd_cn
FROM orders;

5.3 Oracle的EXTRACT与TO_CHAR截断

Oracle的EXTRACT只支持提取YEAR、MONTH、DAY、HOUR、MINUTE、SECOND，不支持直接提取QUARTER和WEEK。如果要按季度分组，一般用TO_CHAR配合格式符：

sql复制SELECT 
    EXTRACT(YEAR FROM create_time) AS y,
    EXTRACT(MONTH FROM create_time) AS m,
    TO_CHAR(create_time, 'Q') AS quarter  -- Q=季度
FROM orders;

Oracle还有一个很有意思的函数TRUNC(date)，它能把日期截断到指定精度：

sql复制-- 截断到当天零点
SELECT TRUNC(SYSDATE) FROM DUAL;
-- 截断到月份第一天
SELECT TRUNC(SYSDATE, 'MM') FROM DUAL;
-- 截断到年份第一天
SELECT TRUNC(SYSDATE, 'YYYY') FROM DUAL;
-- 截断到季度第一天
SELECT TRUNC(SYSDATE, 'Q') FROM DUAL;

这个在“本月第一天”“本季度第一天”这种场景下特别好用，一条TRUNC搞定，不用折腾字符串拼接。

5.4 PostgreSQL的DATE_TRUNC

PostgreSQL的DATE_TRUNC跟Oracle的TRUNC类似，但写法更丰富，支持粒度更细：

sql复制SELECT DATE_TRUNC('month', NOW());
-- 结果: 2024-11-01 00:00:00

SELECT DATE_TRUNC('quarter', NOW());
-- 结果: 2024-10-01 00:00:00

SELECT DATE_TRUNC('week', NOW());
-- 结果: 2024-11-25 00:00:00（按周一为一周开始）

DATE_TRUNC在按时间维度聚合统计时简直是大杀器。以前我用TO_CHAR把时间转成YYYY-MM字符串再去分组，后来发现直接用DATE_TRUNC('month', create_time)分组，出来的结果还是日期类型，排序自然且不会因为字符串格式出问题。

6. 日期条件筛选：索引友好型的写法

6.1 为什么DATE(create_time) = CURDATE()是反面教材

回到文章开头那个慢查询。问题出在DATE(create_time) = CURDATE()这里。create_time列上明明建了索引，但用DATE()函数包裹后，索引就失效了。原因是：你在索引列上做了函数运算，数据库无法直接通过B+树定位到对应的值，只能把每一行的create_time都算一遍再比较，也就是全表扫描。

这个道理用生活中的例子来理解：你有一本按姓名拼音排序的电话本，如果你想找“张三”，直接翻到Z打头的区域就行，这是索引查找。但如果你要找“所有姓名三个字的人”，就得把整本电话本从头到尾翻一遍，这是全表扫描。DATE(create_time)就是这个“数一下名字有几个字”的操作。

正确的做法是用范围查询替代函数查询：

sql复制-- 错误写法：DATE函数导致索引失效
WHERE DATE(create_time) = CURDATE();

-- 正确写法：范围查询，索引友好
WHERE create_time >= '2024-11-25 00:00:00' 
  AND create_time < '2024-11-26 00:00:00';

范围查询的好处是，数据库可以直接利用索引定位到起始位置，然后往后扫描直到边界。这里用>=和<而不是BETWEEN和<=，是为了避免23:59:59.999这种边界时间的精度问题。你永远不知道数据库里存的时间到底是23:59:59.500还是23:59:59.999，但< '2024-11-26 00:00:00'这个条件是无懈可击的。

6.2 计算得到精确的边界值

上面那种写法的问题在于，你需要手动计算第二天的零点。这在实际业务里不可靠，因为今天零点就是CURDATE()，但明天零点是多少？不知道。所以更稳的写法是用日期函数来动态计算：

sql复制-- MySQL
WHERE create_time >= CURDATE()
  AND create_time < CURDATE() + INTERVAL 1 DAY;

-- PostgreSQL和Oracle
WHERE create_time >= CURRENT_DATE
  AND create_time < CURRENT_DATE + INTERVAL '1 day';

-- SQL Server
WHERE create_time >= CAST(GETDATE() AS DATE)
  AND create_time < DATEADD(DAY, 1, CAST(GETDATE() AS DATE));

CURDATE()和CURRENT_DATE返回的就是当天的零点，直接拿来做下边界干净利落。上边界加一天再取不到的那部分，刚好覆盖了当天的全部时间，不会漏也不会多。

6.3 常见日期范围查询的模板

基于上面的思路，我把工作中常用的日期范围查询整理成模板，直接套用就行。以MySQL为例：

sql复制-- 今天
WHERE create_time >= CURDATE() 
  AND create_time < CURDATE() + INTERVAL 1 DAY;

-- 昨天
WHERE create_time >= CURDATE() - INTERVAL 1 DAY 
  AND create_time < CURDATE();

-- 最近7天（含今天）
WHERE create_time >= CURDATE() - INTERVAL 6 DAY;

-- 本月
WHERE create_time >= DATE_FORMAT(CURDATE(), '%Y-%m-01')
  AND create_time < DATE_FORMAT(CURDATE() + INTERVAL 1 MONTH, '%Y-%m-01');

-- 上个月
WHERE create_time >= DATE_FORMAT(CURDATE() - INTERVAL 1 MONTH, '%Y-%m-01')
  AND create_time < DATE_FORMAT(CURDATE(), '%Y-%m-01');

-- 近30天（业务上常用，包含今天共30天）
WHERE create_time >= CURDATE() - INTERVAL 29 DAY;

第七天的计算里，到底是INTERVAL 6 DAY还是INTERVAL 7 DAY，取决于你对“最近7天”的定义。如果要包含今天，就是从今天往前推6天，共7天；如果不包含今天，就是往前推7天到今天之前。这个细节最好在代码注释里写清楚，免得后来的人改错。我在代码评审时经常看到这个数字被反复改来改去，就是没约定好。

7. 日期函数的性能陷阱与优化策略

7.1 隐式类型转换的隐患

日期筛选里还有个常见陷阱，就是隐式类型转换。比如你在WHERE条件里写create_time = '2024-11-25'，如果create_time是DATETIME类型，字符串'2024-11-25'会被自动转成2024-11-25 00:00:00，那当天其他时间的数据就全查不出来了。你以为是查“当天”的数据，实际只查到了“当天的零点那一秒”。

所以条件里的日期字符串，最好显式写成带时间的完整格式，或者用参数化查询的方式传对象类型，不要依赖隐式转换。MySQL在DATETIME列和字符串比较时，会尝试把字符串转成日期，如果格式不对，可能直接报错或给出错误结果。

7.2 对索引列做函数运算的几种N种死法

我在性能优化时总结了对索引列做函数运算的几种典型写法，全部会导致索引失效：

sql复制-- 反面教材1：DATE函数包裹
WHERE DATE(create_time) = '2024-11-25';

-- 反面教材2：YEAR和MONTH组合
WHERE YEAR(create_time) = 2024 AND MONTH(create_time) = 11;

-- 反面教材3：字符串拼接比较
WHERE DATE_FORMAT(create_time, '%Y-%m') = '2024-11';

-- 反面教材4：用LIKE匹配日期前缀
WHERE create_time LIKE '2024-11-25%';

前三个都好理解，第四个LIKE '2024-11-25%'为什么会失效呢？create_time是DATETIME类型，LIKE操作符要求两边都是字符串，数据库就必须先把create_time隐式转成字符串再匹配，索引自然就没了。

正确改法：

sql复制-- 查2024年11月的数据
WHERE create_time >= '2024-11-01 00:00:00' 
  AND create_time < '2024-12-01 00:00:00';

-- 查2024年11月25日的数据
WHERE create_time >= '2024-11-25 00:00:00' 
  AND create_time < '2024-11-26 00:00:00';

7.3 日期范围过大时的进一步优化

如果你查询的条件本身会命中大量数据，就算用了索引，回表造成的额外IO也可能让慢查询变快不到哪去。这时候有几个优化方向：

第一，覆盖索引。如果查询只需要create_time和其他一两个字段，把这个索引设计成包含所有查询列的联合索引，数据库就不用回表了。比如INDEX(create_time, status, amount)，查询返回这三个字段时直接从索引里拿数据。

第二，分页优化。报表类查询如果数据量大，不要用LIMIT 100000, 20这种深分页，性能很差。用“上次查询的最后一条记录的ID或时间作为这次的起点”这种方式来做游标分页，稳定且高效。

第三，物化汇总表。如果是固定维度的趋势分析，比如“近30天每天的订单量”，可以建一个按天汇总的统计表，由一个定时任务去更新。查询只碰这张小表，性能完全没问题。这也是很多BI报表系统的常规做法。

实操心得：有一次做用户活跃度统计，直接查原始日志表，两条SQL把数据库CPU干到90%多。优化方案就是建了月度汇总表，定时任务每小时更新一次，查询走汇总表，CPU瞬间掉到20%。有些问题不该只用SQL技巧去扛，合理地冗余数据才是更优解。

8. 实战案例：一套完整的日期统计SQL

8.1 需求描述

假设我们有一个订单表orders，字段如下：

sql复制CREATE TABLE orders (
    id INT PRIMARY KEY AUTO_INCREMENT,
    order_no VARCHAR(32) NOT NULL,
    user_id INT NOT NULL,
    amount DECIMAL(10, 2) NOT NULL,
    status TINYINT NOT NULL DEFAULT 0,  -- 0待支付 1已支付 2已取消
    create_time DATETIME NOT NULL,
    KEY idx_create_time(create_time),
    KEY idx_user_create(user_id, create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

需求是：输出“本月每天的订单数、支付金额、客单价”，并按日期倒序排列。

8.2 两步走：先算边界，再写主查询

第一步确定边界范围。本月第一天是DATE_FORMAT(CURDATE(), '%Y-%m-01')，下个月第一天是DATE_FORMAT(CURDATE() + INTERVAL 1 MONTH, '%Y-%m-01')。这两个值算好之后，主查询就变成一个普通的范围查询了。

第二步写主查询。按天分组，用DATE(create_time)做分组字段。这里有个性能细节：分组字段用DATE(create_time)没问题，因为分组操作本身要遍历结果集，索引优化作用有限，最关键的还是WHERE条件能命中索引把范围缩小。如果你担心分组字段没法走索引，可以改成BETWEEN范围查询得到的create_time精确值分组，但绝大多数场景下，WHERE能命中索引就够了。

sql复制SELECT 
    DATE(create_time) AS day,
    COUNT(*) AS order_cnt,
    SUM(CASE WHEN status = 1 THEN amount ELSE 0 END) AS paid_amount,
    ROUND(SUM(CASE WHEN status = 1 THEN amount ELSE 0 END) / 
          NULLIF(SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END), 0), 2) AS avg_order_amount
FROM orders
WHERE create_time >= DATE_FORMAT(CURDATE(), '%Y-%m-01')
  AND create_time < DATE_FORMAT(CURDATE() + INTERVAL 1 MONTH, '%Y-%m-01')
GROUP BY DATE(create_time)
ORDER BY day DESC;

这里用NULLIF(..., 0)是为了避免分母为0时报错。如果某天没有已支付的订单，SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END)为0，NULLIF会把0变成NULL，除法结果就是NULL，表示没有客单价可算，而不是报错。这种细节在实际SQL里很常见。

8.3 用ONLY_FULL_GROUP_BY的坑

如果数据库开启了ONLY_FULL_GROUP_BY模式（MySQL 5.7之后默认开启），上面SQL里的SELECT DATE(create_time)没问题，但如果你改成SELECT create_time就会报错。因为GROUP BY DATE(create_time)之后，create_time不是分组字段，也不是聚合函数，MySQL不允许直接查询。

如果确实需要展示某个分组里的具体时间，可以用MIN(create_time)或MAX(create_time)，或者把GROUP BY字段和SELECT字段保持一致，都用DATE(create_time)。这个坑我在接手老项目的代码时经常碰到，很多老SQL在5.6上跑得好好的，迁移到5.7就挂了。

8.4 多日期维度对比的SQL

业务方经常要看“今天的环比昨天”“本周对比上周”。这类需求可以用自关联或者窗口函数实现。以MySQL 8.0为例，用窗口函数LAG取上一期的值：

sql复制WITH daily_stats AS (
    SELECT 
        DATE(create_time) AS day,
        COUNT(*) AS order_cnt,
        SUM(amount) AS total_amount
    FROM orders
    WHERE create_time >= CURDATE() - INTERVAL 13 DAY
    GROUP BY DATE(create_time)
)
SELECT 
    day,
    order_cnt,
    total_amount,
    LAG(order_cnt, 1) OVER (ORDER BY day) AS prev_day_order_cnt,
    ROUND((order_cnt - LAG(order_cnt, 1) OVER (ORDER BY day)) / 
          NULLIF(LAG(order_cnt, 1) OVER (ORDER BY day), 0) * 100, 2) AS day_over_day_pct
FROM daily_stats
ORDER BY day DESC;

这种写法用一次查询就把每天的环比算出来，不用在应用层循环比较。SQL Server和PostgreSQL也支持窗口函数，语法几乎一样，只有Oracle略有差异（Oracle里NULLIF写法和MySQL一样，窗口函数也兼容）。

9. 各数据库日期函数对照表

为了便于查阅，我把主流数据库的日期函数做了一个对照表。

这个表不是让你死记硬背，而是作为开发时的手边参考。真正用得多了，你会发现不同数据库的日期函数逻辑大同小异，核心概念是通的，只是语法略有差异。掌握一门数据库之后，切换其他数据库的成本其实不高。

10. 面试题里的日期函数考点

很多SQL面试题专门考察日期函数，这里列几个常见的题型和解题思路。

10.1 查询累计到昨天的数据

需求：查出从订单表创建以来到昨天的累计订单金额。

sql复制-- MySQL
SELECT 
    DATE(create_time) AS day,
    amount,
    SUM(amount) OVER (ORDER BY DATE(create_time)) AS cumulative_amount
FROM orders
WHERE create_time < CURDATE()
ORDER BY day;

这是在考窗口函数+日期范围，重点在CURDATE()作为边界切割。

10.2 查询每个用户最近一次下单时间

这个考的是分组+取最大日期，但不能直接用MAX把整个查询做完，因为你要的是最近一次的完整记录：

sql复制-- MySQL 8.0 / SQL Server / PostgreSQL
SELECT user_id, create_time, amount
FROM (
    SELECT 
        user_id, create_time, amount,
        ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC) AS rn
    FROM orders
) t
WHERE rn = 1;

如果想用传统写法，先在子查询里取每个用户的最大时间，再跟原表关联：

sql复制SELECT o.*
FROM orders o
INNER JOIN (
    SELECT user_id, MAX(create_time) AS max_time
    FROM orders
    GROUP BY user_id
) t ON o.user_id = t.user_id AND o.create_time = t.max_time;

传统写法有个问题：如果一个用户在同一秒有两条订单，就会查出两条记录。窗口函数写法加ROW_NUMBER()则不会有这个问题，但选哪一条是随机的，这取决于你业务上怎么理解“最近一次”。

10.3 查询各月份订单数对比去年同期

这个题目就是日期函数+条件聚合：

sql复制SELECT 
    MONTH(create_time) AS month_no,
    COUNT(CASE WHEN YEAR(create_time) = YEAR(CURDATE()) THEN 1 END) AS this_year_cnt,
    COUNT(CASE WHEN YEAR(create_time) = YEAR(CURDATE()) - 1 THEN 1 END) AS last_year_cnt
FROM orders
WHERE YEAR(create_time) IN (YEAR(CURDATE()), YEAR(CURDATE())-1)
GROUP BY MONTH(create_time)
ORDER BY month_no;

这里用COUNT(CASE WHEN ...)在一条SQL里同时统计两个年份的数据。技巧点在于条件里用了YEAR(create_time)，如果表数据量大，这种写法性能堪忧。更优的方式仍然是先算出边界再范围查询，这个道理面试时能讲出来，会让面试官眼前一亮。

11. 常见问题与排查技巧实录

11.1 时区问题：日期差8小时

这是最常见的坑，尤其是跨地区部署的系统。MySQL的NOW()返回的是数据库服务器的系统时间，如果服务器时区是UTC，你查出来的“当前时间”就比北京时间慢8小时。

排查步骤：

• 先看数据库时区配置：SHOW VARIABLES LIKE '%time_zone%';，如果system_time_zone是UTC，time_zone是SYSTEM，那用的就是操作系统时区。
• 再看应用服务器时区和业务需求，确认到底应该用哪个时区。
• 修改方式：MySQL可以SET GLOBAL time_zone = '+08:00'，但重启会失效，最好在配置文件[mysqld]里写default-time-zone = '+08:00'。

注意：TIMESTAMP类型会自动转换时区，DATETIME不会。同样是存储一条记录，TIMESTAMP会根据会话时区显示不同的值，DATETIME存什么显示什么。如果你发现同一列有人看到的时间差8小时，先检查类型是哪个，再检查会话时区。

11.2 SQL报错“Incorrect datetime value”

这个错误通常是因为传入了无法识别的日期字符串，比如'2024-13-01'（13月）或'2024-11-31'（11月没有31号）。MySQL 5.7之后严格模式默认开启，非法日期会直接报错而不是存0值。

还有一种情况是日期字符串里混入了奇怪的字符，比如'2024-11-25T14:30:45'这种ISO格式。MySQL能识别T，但有些版本/环境可能不接受。自己在代码里踩过这个坑后，我养成了一个习惯：**在写入或查询之前，先在应用层用datetime.strptime之类的工具做一次严格解析，确认格式正规再交给SQL。**这样数据库报错会少很多。

11.3 慢查询日志里日期查询尤其多

如果你发现慢查询日志里大量是日期相关的SQL，大概率是应用在定时任务里跑统计数据，或者查询条件里日期写法不够高效。建议：

• 先看SQL是不是对索引列做了函数运算，这是最常见的性能杀手。
• 再看是不是查询范围过大，比如create_time BETWEEN '2024-01-01' AND '2024-11-25'这种查询全年数据的SQL，就算有索引也会扫描大量行。
• 最后看是否需要预先聚合，如果业务允许，用汇总表来承载这类统计查询。

11.4 数据库之间迁移生僻函数报错

有一次我帮团队把系统从MySQL迁到PostgreSQL，结果一大片SQL报错，全都是日期函数的语法差异。MySQL的DATE_FORMAT在PostgreSQL里不存在，STR_TO_DATE也不存在。后来我在迁移过程中写了个函数映射表，批量替换这些差异函数，才顺利上线。

如果你经常维护多套数据库的代码，建议把日期操作的公共逻辑抽象成应用层工具类，SQL层只做SELECT和WHERE的基础操作。这样能大大减少数据库方言差异带来的痛苦。

12. 最后分享几点我的使用习惯

日期函数看着基础，但恰恰是这种基础能力决定了你在处理真实业务时顺不顺手。最后分享几个我在实际项目中奉行的小习惯。

第一，能不用函数就不用函数。所有条件判断优先写成范围查询，让数据库用索引说话。DATE(create_time) = '2024-11-25'这种写法虽然简洁，但一次两次没问题，数据量上来就是灾难。

第二，参数化查询永远比拼字符串更可靠。不光是安全问题，类型上更稳妥。Java后端用PreparedStatement传java.time.LocalDateTime，比传字符串让数据库隐式转换靠谱得多。

第三，日期计算的边界值一定要测。每个月最后一天、每年最后一天、闰年2月29日，这些数字测试工程师大概率不会全覆盖，你作为开发者要自己心里有数。

第四，不要忽视代码可读性。日期条件写成一堆魔法数字和函数嵌套，过两周你自己都看不懂。我习惯在复杂日期计算前加一行注释，写明“这段SQL是计算上个月第一天到下个月第一天，用于本月统计”，后面维护的人会感激你。

写SQL本身是个熟能生巧的过程，日期函数作为其中最常碰到的部分，多踩几次坑、多总结几次，就会形成肌肉记忆。希望这篇文章能帮你少走一些我当年走过的弯路。如果在实际开发中遇到了这里没提到的日期问题，欢迎留言一起讨论。