YEAR()和MONTH()函数仅适用于DATE/DATETIME/TIMESTAMP类型字段，不可用于字符串或NULL；MySQL、SQL Server原生支持，PostgreSQL需用EXTRACT(YEAR FROM ...)，SQLite须用strftime('%Y', ...)，且WHERE中直接使用会导致索引失效。
YEAR() 和 MONTH() 函数能直接提取年份和月份，但必须作用于合法的日期类型字段；对字符串或 NULL 值调用会返回 NULL 或报错，不是所有数据库都支持这两个函数。
YEAR() 和 MONTH() 在不同数据库中的可用性
MySQL、PostgreSQL（需用 EXTRACT(YEAR FROM ...)）、SQL Server 都支持 YEAR() 和 MONTH()，但 SQLite 默认不支持——它要用 strftime('%Y', ...) 和 strftime('%m', ...)。PostgreSQL 更推荐用标准 SQL 的 EXTRACT()，因为 YEAR() 是它的非标准别名函数，某些版本可能未启用。
- MySQL：直接用
YEAR(order_date)、MONTH(order_date) - PostgreSQL：优先写
EXTRACT(YEAR FROM order_date)（返回 numeric 类型） - SQLite：必须用
strftime('%Y', order_date)，注意返回的是字符串 - SQL Server：支持
YEAR(order_date)，也支持DATEPART(YEAR, order_date)
常见错误：字段不是 DATE/DATETIME 类型
如果 order_date 实际是 VARCHAR 存储（如 '2023-10-05'），MySQL 可能隐式转换成功，但 PostgreSQL 会直接报错 function year(unknown) does not exist。这时候必须先显式转类型：
SELECT YEAR(CAST('2023-10-05' AS DATE)); -- MySQL/SQL Server 可行
SELECT EXTRACT(YEAR FROM '2023-10-05'::DATE); -- PostgreSQL
SELECT strftime('%Y', '2023-10-05'); -- SQLite- 别依赖隐式转换，尤其跨库迁移时行为不一致
- 检查字段真实类型：
DESCRIBE orders;（MySQL）或\d orders（psql） - 字符串格式不规范（如 '05/10/2023'）会导致 CAST 失败，得先用
STR_TO_DATE()或正则清洗
WHERE 条件中误用 YEAR()/MONTH() 导致索引失效
写 WHERE YEAR(created_at) = 2023 看似简洁，但数据库无法用上 created_at 字段的索引，全表扫描风险高。等价且高效写法是：
WHERE created_at >= '2023-01-01' AND created_at < '2024-01-01'
- 同理，查“2023 年 10 月”应写成
created_at >= '2023-10-01' AND created_at - 用函数包裹字段几乎都让索引失效，
MONTH()同理 - 如果真要按年月聚合分析，可考虑加计算列 + 索引（MySQL 5.7+ 支持）
真正麻烦的不是函数怎么写，而是字段类型是否可信、查询是否走索引、以及跨数据库语法差异带来的隐形兼容问题——这些在本地测试时往往看不出来，上线后才暴露。
