先说几句：用YEAR()和MONTH()提取时间里的年份或月份，本身不算复杂，但一个常见坑在于——数据源到底是什么类型？这俩函数只能处理DATE、DATETIME或TIMESTAMP字段，对字符串或NULL下手，结果要么报错，要么返回NULL。还要注意，不是所有数据库都原生支持这两个函数。
YEAR() 和 MONTH() 函数能直接提取年份和月份，但必须作用于合法的日期类型字段；对字符串或 NULL 值调用会返回 NULL 或报错，不是所有数据库都支持这两个函数。
数据库兼容性这块，足够让人头疼。MySQL可以直接写YEAR(order_date)；SQL Server也支持，或者用DATEPART(YEAR, order_date)。但PostgreSQL就得另辟蹊径了，官方推荐的是标准SQL的EXTRACT(YEAR FROM ...)，至于YEAR()这个写法，虽然部分版本也能用，但它其实是个非标准别名，不一定默认开启。SQLite更另类，干脆不支持这两个函数，得用strftime('%Y', order_date)——注意，它返回的是字符串，不是数字。
- 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)
字段类型不符也是个常见的翻车点。如果约定的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条件里的索引问题。比如写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 < '2023-11-01'。这种方式既保证了查询效率，也规避了函数导致的索引失效问题。
当然，如果业务上确实经常需要按年月做聚合分析，也有更优雅的解法——比如在MySQL 5.7+中，可以考虑加一个计算列并为其建索引，这样既可以用函数查询，又能充分利用索引。
说到底，真正让人头疼的不是函数怎么写，而是字段类型是否靠谱、查询能不能避开全表扫描、以及不同数据库间语法差异带来的隐性兼容问题。这些隐患在本地开发时往往被忽略，真正上了线才出来折磨人。
