不安全，直接使用 YEAR() 和 MONTH() 会导致索引失效、全表扫描；应改用范围查询，如 WHERE order_date >= '2024-05-01' AND order_date

YEAR() 和 MONTH() 函数在 WHERE 子句中直接使用是否安全？

不安全，尤其当字段上有索引时。直接对日期列套用 YEAR(created_at) 或 MONTH(created_at) 会让数据库无法走索引，全表扫描风险高。MySQL、PostgreSQL、SQL Server 都存在这个问题。真正高效的方式是构造范围条件，而不是提取年月再比较。

按“2024年5月”筛选的正确写法（避免函数包裹日期列）

用闭区间范围代替 YEAR() + MONTH() 组合判断。假设表有 order_date 字段（类型为 DATE 或 DATETIME），筛选 2024 年 5 月全部数据：

WHERE order_date >= '2024-05-01'
  AND order_date < '2024-06-01'

这个写法能命中索引，且语义清晰——它等价于“>= 5月第一天 且 而不是 ，避免跨月误差。

• 不要写 WHERE YEAR(order_date) = 2024 AND MONTH(order_date) = 5 —— 索引失效
• 不要依赖 DATE_FORMAT(order_date, '%Y-%m') 做字符串匹配 —— 同样无法索引
• 如果字段是 TIMESTAMP 且带时区，需确认数据库时区设置，否则边界可能偏移

需要动态生成月份范围时，怎么写才不容易出错？

手动拼日期字符串易错，推荐用数据库内置日期函数构造边界。例如 MySQL 中获取“上个月”的范围：

WHERE order_date >= DATE_FORMAT(DATE_SUB(CURDATE(), INTERVAL 1 MONTH), '%Y-%m-01')
  AND order_date < DATE_FORMAT(CURDATE(), '%Y-%m-01')

PostgreSQL 可用：WHERE order_date >= DATE_TRUNC('month', NOW() - INTERVAL '1 month') AND order_date

• DATE_TRUNC（PostgreSQL）、DATE_FORMAT + DATE_SUB（MySQL）比手写字符串更可靠
• 避免用 BETWEEN，它包含两端，而月份右边界用 更精确、无歧义
• 如果业务要求严格按“自然月”，且数据含未来时间，记得检查 order_date 是否有 NULL 或非法值，它们会意外进入结果集

为什么有些场景还是不得不写 YEAR()/MONTH()？

仅限于聚合分组或计算列场景，比如统计每月订单数：

SELECT YEAR(order_date) AS y, MONTH(order_date) AS m, COUNT(*) 
FROM orders 
GROUP BY YEAR(order_date), MONTH(order_date)

这时函数出现在 SELECT 和 GROUP BY 中，不影响过滤性能，但要注意：

• GROUP BY 中必须和 SELECT 列一致，不能只写 GROUP BY y, m（部分数据库不支持别名）
• 如果想按“2024-05”字符串分组，用 DATE_FORMAT(order_date, '%Y-%m') 更直观，但 PostgreSQL 需用 TO_CHAR(order_date, 'YYYY-MM')
• 这种写法无法利用索引加速 GROUP BY，大数据量时考虑加覆盖索引，如 (order_date, id)

真正容易被忽略的是：哪怕只是临时查一个月，只要 WHERE 里对日期字段用了函数，索引就废了——这点在慢查询分析时经常被绕过。