year()和month()函数直观但低效，因函数包裹使索引失效；推荐用日期范围查询（如between）以利用索引提升性能。
用 YEAR() 和 MONTH() 提取并过滤日期字段
直接对日期字段做范围比较更高效，但如果你手头只有字符串型日期（比如 '2023-05-12'），或想快速按年/月粗筛，YEAR() 和 MONTH() 是最直觉的选择。注意它们只适用于 MySQL、SQL Server 等支持该函数的数据库；PostgreSQL 要用 EXTRACT(YEAR FROM ...)，SQLite 用 strftime('%Y', ...)。
常见错误是写成 WHERE YEAR(date_col) = '2023' —— 字符串和整数比较可能触发隐式转换，建议统一用数字：
SELECT * FROM orders WHERE YEAR(order_date) = 2023 AND MONTH(order_date) = 5;
- 该写法无法利用
order_date上的索引（函数包裹导致索引失效） - 若
order_date允许为NULL，YEAR(NULL)返回NULL，这条记录会被自动排除 - 跨年查询（如“2022 年下半年”）需改用
BETWEEN或逻辑组合，别硬套两个函数
用日期范围查询（推荐：走索引、兼容性强）
真正要查“某个月份的所有数据”，应该算出该月的起止时间点，用 BETWEEN 或开区间比较。这样能命中 date_col 的 B-Tree 索引，性能差异可能达数量级。
例如查 2023 年 5 月全部记录：
SELECT * FROM events WHERE event_time >= '2023-05-01' AND event_time
- 用
而不是 <code>，避免时分秒精度丢失和夏令时问题 - 字符串字面量格式必须符合数据库默认日期格式，MySQL 默认接受
'YYYY-MM-DD'，PostgreSQL 更严格，建议显式转类型：::DATE或CAST(... AS DATE) - 如果字段是
TIMESTAMP WITH TIME ZONE，务必确认时区上下文——'2023-05-01'默认按数据库时区解释
查“所有历史数据”时小心 NULL 和边界值
“所有历史数据”听起来简单，但实际常隐含陷阱：比如业务中把“未发生”记为远期未来时间（'9999-12-31'），或把“未知日期”设为 NULL 或 '0000-00-00'（MySQL 传统模式）。直接 WHERE date_col 会漏掉这些。
- 先确认数据质量：
SELECT COUNT(*), COUNT(date_col), MIN(date_col), MAX(date_col) FROM table; - 若存在
NULL且你希望包含，得显式加条件：OR date_col IS NULL - MySQL 中
'0000-00-00'不被标准函数识别，YEAR('0000-00-00')返回0，但'0000-00-00' 为 <code>TRUE—— 行为不一致，建议清洗掉
PostgreSQL / SQLite 用户注意函数名差异
别直接复制 MySQL 写法到其他数据库，否则报错或结果错乱。核心是区分“提取年月”和“生成范围”两类操作：
提取年月：
- PostgreSQL：
EXTRACT(YEAR FROM order_date)、EXTRACT(MONTH FROM order_date) - SQLite：
strftime('%Y', order_date)、strftime('%m', order_date)（返回字符串，需CAST(... AS INT)比较）
生成本月范围（以 PostgreSQL 为例）：
SELECT * FROM logs
WHERE log_time >= DATE_TRUNC('month', CURRENT_DATE)
AND log_time <p>SQLite 没有原生月计算，得靠字符串拼接或 <code>strftime</code> 组合，容易出错，真要频繁按月查，建议加一个生成的 <code>year_month CHAR(7)</code> 字段（如 <code>'2023-05'</code>）并建索引。</p><p>最易被忽略的是时区和字段精度：同一个 <code>2023-05-01</code> 在 UTC 和 CST 下代表不同时间窗口，而 <code>DATETIME</code> 和 <code>TIMESTAMP</code> 在 MySQL 中处理方式也不同。动手前先 <code>SELECT @@time_zone, @@sql_mode;</code> 看清环境。</p>
