SQL中DATEPART函数提取日期中的年份或月份

写SQL的时候，但凡跟日期打交道，免不了碰上提取年份或月份的需求。很多人第一反应就是DATEPART——这个函数在SQL Server和Azure SQL里确实好用，但换个数据库就得另找路子。MySQL认YEAR()和MONTH()，PostgreSQL用EXTRACT()，SQLite则靠strftime()。千万别以为函数名能跨平台通用，否则上线报错时哭都来不及。

DATEPART 在 SQL Server 中提取年份或月份

先说清楚：DATEPART 是 SQL Server 和 Azure SQL 的原生函数，MySQL、PostgreSQL 或 SQLite 压根没有这个关键字。如果其他数据库里报错，不是写法出了偏差，而是那个函数根本不存在。

用法倒不复杂，但参数顺序固定：DATEPART(datepart, date)。第一个参数是你想取的单位（比如 year 或 month），第二个是日期表达式。

• DATEPART(year, '2023-04-15') → 返回 2023
• DATEPART(month, '2023-04-15') → 返回 4（注意，不会补零成 04）
• 支持的 datepart 值挺多：year、quarter、month、day、week、weekday、hour 等等
• 有个小坑：weekday 默认以周日为第一天（值为 1），想改的话得靠 SET DATEFIRST 调整

MySQL / PostgreSQL 怎么替代 DATEPART？

别硬套 DATEPART，各数据库有自己的一套函数，强行改名只会收获报错。

• MySQL：直接用 YEAR() 和 MONTH()，比如 YEAR('2023-04-15') → 2023；MONTH('2023-04-15') → 4
• PostgreSQL：用 EXTRACT()，语法是 EXTRACT(YEAR FROM '2023-04-15'::date)。注意要显式转类型，否则字段类型推导可能翻车
• SQLite：用 strftime()，比如 strftime('%Y', '2023-04-15') 返回字符串 '2023'，strftime('%m', '2023-04-15') 返回 '04'（带前导零，跟 SQL Server 的整数返回不一样）

常见错误：把 DATEPART 当成通用函数用

这是跨数据库迁移时最常踩的坑——开发在 SQL Server 上写了 DATEPART(year, order_date)，上线到 MySQL 就直接报错 FUNCTION DATEPART does not exist。

• 不查文档就假设函数跨平台，等于拿锤子找所有钉子，迟早碰壁
• ORM 框架（比如 Entity Framework、Django ORM）生成的 SQL 可能会自动适配，但手写 SQL 不会那么智能
• 如果必须兼容多库，建议把日期提取逻辑移到应用层，或者用视图加条件分支封装一把

性能和隐式转换陷阱

DATEPART 本身执行效率并不低，但容易触发索引失效——尤其当它套在列上时，比如 WHERE DATEPART(year, created_at) = 2023。

• 这会让 SQL Server 无法使用 created_at 列上的索引，全表扫描风险陡增
• 更高效的写法是范围查询：WHERE created_at >= '2023-01-01' AND created_at < '2024-01-01'
• 另外注意：如果传入 NULL，DATEPART 返回 NULL，不是 0 或空字符串，做分组或过滤时得提前处理

实际用哪个函数，取决于你连的是哪套数据库，而不是“哪个更顺口”。跨库时函数名只是表象，底层时间模型（比如是否区分时区、是否支持微秒）才是真正影响结果一致性的部分。