日期处理是SQL查询中的基础技能，从日期字段里提取“当年第几月”更是数据报表、账单统计中的高频需求。不同的数据库提供了不同的函数，比如MySQL的MONTH()、SQL Server的DATEPART()、PostgreSQL的EXTRACT()，如果没搞清楚差异，换库之后很容易写出无法执行的SQL。这篇文章会从最直接的函数用法入手，逐步拆解各个数据库的写法，并深入分析月份提取在真实业务场景中的应用和性能瓶颈。
一、使用MONTH函数直接获取月份
在所有数据库函数中，MONTH()是最直观的一种。它接收一个日期或日期时间表达式，返回一个介于1到12之间的整数，表示该日期所在的月份。MySQL和SQL Server都原生支持这个函数，用法也完全一致。例如，MONTH('2024-06-15')会返回整数6。如果参数是带时间的日期，比如'2024-06-15 14:30:00'，同样返回6，因为它只关心日期部分。
在PostgreSQL中，MONTH()函数并不存在，取而代之的是EXTRACT(MONTH FROM date)。需要注意的是，PostgreSQL的EXTRACT()返回的是numeric类型，而MySQL的MONTH()返回int类型。如果后续有整数运算，类型差异可能带来隐式转换，需要格外留意。Oracle的写法是EXTRACT(MONTH FROM date)，但要求参数必须是完整的日期类型，不能直接传入字符串，否则会报错。
下面这段代码展示了不同数据库中最简单的月份提取方式：
-- MySQL / SQL Server
SELECT MONTH('2024-06-15') AS month_of_year;
-- PostgreSQL
SELECT EXTRACT(MONTH FROM DATE '2024-06-15') AS month_of_year;
-- Oracle
SELECT EXTRACT(MONTH FROM DATE '2024-06-15') FROM dual;
这段代码中的注释标明了数据库类型，实际使用时需要替换为对应的连接环境。对于SQLite这类轻量级数据库，并没有原生MONTH()函数，通常使用strftime('%m', date)来获取两位月份字符串，例如strftime('%m', '2024-06-15')会返回'06'，而不是数字6，这是一个容易被忽视的差异。
二、常用数据库月份函数对比
为了帮助你在不同数据库之间快速切换，这里整理了一张主流数据库的月份提取方式对照表。注意，同名函数在不同数据库中的行为可能不同，建议在切换数据库时查阅官方文档。
| 数据库 | 函数写法 | 返回类型 |
|---|---|---|
| MySQL | MONTH(date) | INT |
| SQL Server | MONTH(date) 或 DATEPART(month, date) | INT |
| PostgreSQL | EXTRACT(MONTH FROM date) | NUMERIC |
| Oracle | EXTRACT(MONTH FROM date) | NUMBER |
| SQLite | strftime('%m', date) | TEXT |
从这个表格能看出，功能相似的函数在参数顺序上存在差异。SQL Server的DATEPART把日期部分名称放在第一位，日期放在第二位；而PostgreSQL和Oracle的EXTRACT则把MONTH FROM date当作一个整体结构来解析。如果记混了，轻则语法报错，重则返回错误的查询结果。
另外，MONTH()函数在大多数数据库中不能直接接受字符串，除非该字符串能被隐式转换为日期。MySQL对字符串的容忍度较高，但Oracle和PostgreSQL则要求显式使用DATE关键字或CAST转换。因此，处理动态传入的参数时，最好统一先做类型转换，再提取月份，避免因为隐式转换规则不同导致跨数据库乱码或报错。
三、按月份分组统计的业务场景
提取月份本身不是目的，最终还是要服务于业务分析。最常见的场景是统计每个月的销售额、订单量或活跃用户数。这类查询通常会把月份字段放在GROUP BY子句中，同时配合年份条件，防止不同年份的数据混在一起。
下面是一个按月份统计订单销售额的MySQL示例：
-- MySQL 按月份统计2024年订单总额
SELECT
MONTH(order_date) AS sale_month,
SUM(amount) AS total_amount
FROM orders
WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY MONTH(order_date)
ORDER BY sale_month;
这个查询返回一张包含12行结果的小表，每一行对应一个月份和该月份的销售总额。如果某个月没有订单，这个月份会直接缺席，而不是显示0。若要补全缺失月份，通常需要借助数字辅助表或递归CTE生成1到12的月份序列，再左连接统计数据。
在PostgreSQL中，由于EXTRACT()返回数值，因此GROUP BY子句可以直接使用EXTRACT(MONTH FROM order_date)，但要注意ORDER BY时也应该引用相同的表达式，否则可能出现排序不一致。SQL Server的DATEPART同样适用，不过它返回的整数可以直接参与加减运算，这在计算环比、同比时很有用。
再来看一个更复杂的场景：按季度汇总数据。首先提取月份，然后利用整除或CASE表达式把月份映射到季度。例如CEIL(MONTH(date) / 3.0)可以计算出季度号，这在MySQL和SQL Server中都能运行。虽然这个需求超出了“第几月”，但它说明了月份提取是一切时间序列分析的基础。
四、日期函数使用中的性能陷阱与优化
直接在日期列上使用MONTH()这类函数，往往会导致索引失效。因为函数将每一行的日期值都转换成了月份整数，数据库无法直接利用B-Tree索引进行范围扫描。举个例子，如果订单表order_date列上有索引，但查询条件写成WHERE MONTH(order_date) = 6，这个查询会执行全表扫描，而不是索引查找。
更推荐的做法是把条件改写成范围查询。比如要查询6月的订单，应该写成：
-- 避免在索引列上使用函数 SELECT * FROM orders WHERE order_date >= '2024-06-01' AND order_date < '2024-07-01';
在这个示例中，<在代码块内被转义为<，这是为了确保HTML正确渲染。实际执行时，数据库会把这个条件解析为两个边界值，从而走索引范围扫描。同样的逻辑也适用于按年、按天查询。如果业务上必须按月份聚合，宁愿先限定日期范围，再在SELECT和GROUP BY中使用月份函数，也不要直接对全表做函数运算。
时区问题也会影响月份提取。如果一个数据表存储的是UTC时间，而业务需要统计北京时间所属的月份，那么直接使用MONTH(utc_time)可能得到错误的日期。此时需要先进行时区转换，例如在PostgreSQL中使用timezone('Asia/Shanghai', utc_time)，然后再提取月份。时区转换本身也是一种函数运算，同样可能影响索引使用，因此在设计表结构时，最好明确存储的时间标准，并尽量在写入数据时就转换为业务本地时间。
五、扩展：同时获取年份和月份
有时候我们需要查询结果只显示“2024-06”这样的格式，而不只是数字6。这时可以把年份和月份拼接起来。在MySQL中，可以使用DATE_FORMAT(date, '%Y-%m')直接格式化；在PostgreSQL中，可以用TO_CHAR(date, 'YYYY-MM')；SQL Server则使用FORMAT(date, 'yyyy-MM')。这些格式化函数返回的是字符串，适合用于报表展示。
但字符串形式的月份在排序时需要注意，因为纯字符串排序可能按字典序而不是时间顺序。例如'2024-10'会排在'2024-09'前面，因为字符串比较是一位一位比较的。所以如果要对月份排序，最好仍然用数字形式，或者使用正确的格式化方式确保字符串能被按时间顺序排序。对于PostgreSQL，TO_CHAR输出的月份字符串如果使用YYYY-MM格式，恰好可以按字典序排序，因为年份和月份都是定长的。但其他数据库需要根据具体格式判断。
从这些细节可以看出，提取日期月份看似简单，但背后涉及函数兼容性、数据类型、索引优化、时区转换等多个层面的问题。掌握这些之后，你就能在写SQL时少走弯路，写出既正确又高效的时间查询语句。