写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')→ 返回2023DATEPART(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 或空字符串，做分组或过滤时得提前处理
实际用哪个函数，取决于你连的是哪套数据库，而不是“哪个更顺口”。跨库时函数名只是表象，底层时间模型（比如是否区分时区、是否支持微秒）才是真正影响结果一致性的部分。
