正确写法是WHERE YEAR(date_column) = 年份，但需确保字段为DATE/DATETIME/TIMESTAMP类型；字符串需标准格式，否则隐式转换失败；YEAR(NULL)返回NULL导致数据丢失；函数使索引失效，建议改用范围查询如created_at >= '2023-01-01' AND created_at

MySQL中用YEAR()提取年份并筛选的正确写法

直接在WHERE子句里用YEAR(date_column)是最常用也最直观的方式，但要注意字段类型必须是DATE、DATETIME或TIMESTAMP，否则会静默返回NULL导致查不到数据。

例如筛选2023年的订单：

SELECT * FROM orders WHERE YEAR(created_at) = 2023;

• 如果created_at是字符串（如'2023-05-12'），MySQL会尝试隐式转换，但遇到格式不标准（如'2023/05/12'或'12-MAY-2023'）就失效
• YEAR()对NULL值返回NULL，所以该行一定不会被选中——这点常被忽略，导致“明明有数据却查不出来”
• 函数作用于字段会使索引失效，大数据量时建议改用范围查询（见下一条）

为什么YEAR()可能让索引失效？用范围查询替代更高效

当写成YEAR(created_at) = 2023，MySQL无法利用created_at上的B+树索引，只能全表扫描。换成日期范围就能走索引：

SELECT * FROM orders WHERE created_at >= '2023-01-01' AND created_at < '2024-01-01';

• 这个写法兼容所有日期类型，且能命中created_at索引（前提是该字段有索引）
• 注意用而不是<code>，避免因毫秒或时区引发边界遗漏
• 如果字段是DATE类型（无时间部分），也可以，但统一用左闭右开区间更安全

PostgreSQL和SQL Server不能用YEAR()，得换函数

MySQL专属的YEAR()在其他数据库里不存在。跨数据库写法要调整：

• PostgreSQL：用EXTRACT(YEAR FROM date_column)，例如 WHERE EXTRACT(YEAR FROM created_at) = 2023
• SQL Server：用YEAR(date_column)——名字一样但属于T-SQL，不是标准SQL；也可用DATEPART(YEAR, date_column)
• SQLite：用strftime('%Y', date_column)，注意参数顺序和单引号
• 所有这些函数同样会导致索引失效，生产环境仍推荐范围查询替代

日期字段存成字符串时，YEAR()完全不可靠

如果设计时把日期存为VARCHAR（比如'2023-05-12'），YEAR()看似能用，实则埋雷：

• 一旦出现'20230512'、'12/05/2023'或空格填充，YEAR()直接返回NULL
• 即使格式统一，字符串比较和日期比较逻辑不同——比如'2023-13-01'会被MySQL转成0000-00-00，YEAR()返回0
• 真正可靠的解法是先用STR_TO_DATE()（MySQL）或TO_DATE()（PostgreSQL）转成日期类型再处理，但性能差且需预判格式

历史数据清洗比临时函数补救更值得投入时间。