DATEPART仅在SQL Server及Azure SQL中支持，用于提取年份（YEAR）或月份（MONTH）等日期部分，返回整数；MySQL用YEAR()/MONTH()，PostgreSQL用EXTRACT(YEAR FROM date)，SQLite用strftime('%Y', date)。
DATEPART 在 SQL Server 中提取年份或月份
DATEPART 只在 SQL Server（及 Azure SQL）中原生支持，MySQL、PostgreSQL 或 SQLite 都没有这个函数。如果你在其他数据库里看到 DATEPART 报错，不是写法问题，而是根本不存在。
它用法简单但参数顺序固定：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'（带前导零）
常见错误：把 DATEPART 当成通用函数用
这是跨数据库迁移时最常踩的坑——开发在 SQL Server 上写了 DATEPART(year, order_date)，上线到 MySQL 就直接报错 FUNCTION DATEPART does not exist。
- 不查文档就假设函数跨平台，等于拿锤子找所有钉子
- ORM 框架（如 Entity Framework、Django ORM）生成的 SQL 可能自动适配，但手写 SQL 不会
- 如果必须兼容多库，建议把日期提取逻辑移到应用层，或用视图/CTE + 条件分支封装
性能和隐式转换陷阱
DATEPART 本身不慢，但容易触发索引失效——尤其当它套在列上时，比如 WHERE DATEPART(year, created_at) = 2023。
- 这会让 SQL Server 无法使用
created_at列上的索引，全表扫描风险高 - 更高效写法是范围查询：
WHERE created_at >= '2023-01-01' AND created_at - 另外注意：如果传入
NULL，DATEPART返回NULL，不是 0 或空字符串，做分组或过滤时得提前处理
实际用哪个函数，取决于你连的是哪套数据库，而不是“哪个更顺口”。跨库时函数名只是表象，底层时间模型（比如是否区分时区、是否支持微秒）才是真正影响结果一致性的部分。
