EXTRACT函数在PostgreSQL、Oracle和MySQL 8.0+中支持YEAR/MONTH等标准语法，但MySQL 5.7及旧版SQL Server不支持；SQL Server须用DATEPART(YEAR, date)，SQLite需用strftime('%Y', date)，跨库应优先考虑兼容性写法并注意类型转换与时区影响。
EXTRACT 函数在不同数据库中的语法差异
EXTRACT 不是 SQL 标准中完全统一的函数，PostgreSQL、Oracle、MySQL 8.0+ 和 SQL Server（仅部分版本通过 DATEPART 兼容）支持它，但参数写法和可提取字段范围不同。最常见踩坑是把 EXTRACT(YEAR FROM date_col) 直接套用到 MySQL 5.7 或旧版 SQL Server 上——它们根本不认这个语法。
PostgreSQL 和 Oracle 支持完整形式：EXTRACT(YEAR FROM some_date)、EXTRACT(MONTH FROM some_date)；MySQL 8.0+ 也支持，但必须确保日期表达式类型为 DATE、DATETIME 或 TIMESTAMP，传入字符串（如 '2023-05-12'）会隐式转换，但若格式不标准（如 '12/05/2023'）可能返回 NULL。
如何安全提取年份和月份（含兼容性建议）
如果目标库明确是 PostgreSQL 或 Oracle，直接用 EXTRACT 最简洁；否则优先考虑更通用的函数，避免迁移时出错。
- PostgreSQL / Oracle：用
EXTRACT(YEAR FROM order_date)和EXTRACT(MONTH FROM order_date) - MySQL 8.0+：同样可用
EXTRACT，但YEAR(order_date)和MONTH(order_date)更直观且兼容 5.7 - SQL Server：必须改用
DATEPART(YEAR, order_date)和DATEPART(MONTH, order_date)，EXTRACT无效 - SQLite：没有
EXTRACT，得用strftime('%Y', order_date)和strftime('%m', order_date)
常见错误：NULL 结果或类型报错
返回 NULL 通常不是函数写错了，而是源字段本身为 NULL，或类型不匹配。比如对 TEXT 字段（存的是 '2023-05'）直接 EXTRACT(MONTH FROM text_col)，PostgreSQL 会报错「function extract(unknown, text) does not exist」。
解决办法：
- 先确认字段类型：
\d table_name（PostgreSQL）或DESCRIBE table_name（MySQL） - 强制转换再提取：
EXTRACT(YEAR FROM CAST(created_at AS DATE)) - 加
WHERE created_at IS NOT NULL过滤空值，避免聚合时被意外忽略 - 注意时区影响：PostgreSQL 中
TIMESTAMPTZ字段提取的是本地时区对应的年月，不是 UTC 时间
性能与索引注意事项
EXTRACT(YEAR FROM created_at) 这类表达式无法走 created_at 字段上的普通 B-tree 索引，因为它是计算列。如果高频按年月查询（如 WHERE EXTRACT(YEAR FROM created_at) = 2023），要么改写成范围查询：WHERE created_at >= '2023-01-01' AND created_at ，要么建函数索引（PostgreSQL）：CREATE INDEX idx_orders_year ON orders (EXTRACT(YEAR FROM created_at))。
MySQL 不支持函数索引（直到 8.0.13 才支持函数索引，且只限于存储函数），所以更推荐范围写法。
真正容易被忽略的是：跨年份做 GROUP BY EXTRACT(YEAR FROM ...), EXTRACT(MONTH FROM ...) 时，如果数据量大又没覆盖索引，执行计划里很可能出现全表扫描——别只盯着函数怎么写，得看执行计划里有没有用上索引。
