查本周数据应使用YEARWEEK(create_time, 1) = YEARWEEK(NOW(), 1)，因其按ISO标准自动处理跨年问题；查本月数据宜用左闭右开范围查询避免索引失效；时区敏感场景须确保输入时间已对齐业务时区。
查本周数据：用 YEARWEEK() 比 DATE_FORMAT() 更可靠
直接用 DATE_FORMAT(NOW(), '%Y%u') 拼字符串看似简单，但跨年时会出错——比如 2024-12-30 是 2025 年第 1 周，'202453' 和 '202501' 对不上。YEARWEEK() 默认按周一为周始、ISO 标准（mode=1），能自动处理跨年问题。
实操建议：
- 查本周数据：
WHERE YEARWEEK(create_time, 1) = YEARWEEK(NOW(), 1) - 若业务以周日为周始，改用
mode=0：YEARWEEK(create_time, 0) -
create_time字段必须是DATETIME或TIMESTAMP类型；如果是DATE，也兼容，但别用CHAR/VARCHAR存时间
查本月数据：优先用范围查询，别依赖 DATE_FORMAT()
DATE_FORMAT(create_time, '%Y-%m') = DATE_FORMAT(NOW(), '%Y-%m') 看似直观，但会导致索引失效——因为对字段用了函数，MySQL 无法使用 create_time 上的普通 B-tree 索引。
实操建议：
- 用左闭右开区间：
WHERE create_time >= DATE(NOW()) - INTERVAL (DAY(NOW())-1) DAY AND create_time - 更清晰写法（推荐）：
WHERE create_time >= LAST_DAY(NOW() - INTERVAL 1 MONTH) + INTERVAL 1 DAY AND create_time - 如果表数据量大，确保
create_time有索引；复合查询中避免在它上面套任何函数
DATE_FORMAT() 的典型误用场景和替代方案
很多人用 DATE_FORMAT() 做条件过滤或分组，结果慢、不准、难调试。它真正适合的场景是「格式化输出」，不是「逻辑判断」。
常见错误现象：
- 写
WHERE DATE_FORMAT(create_time, '%Y%m%d') = '20240520'→ 全表扫描，哪怕有索引 - 用
GROUP BY DATE_FORMAT(create_time, '%Y-%m')分月统计 → 无法利用索引加速排序，大数据量下内存占用高 - 把
DATE_FORMAT(NOW(), '%Y-%m-%d %H:00:00')当时间截断用 → 不如直接DATE_SUB(NOW(), INTERVAL SECOND(NOW()) SECOND)
替代思路：用 DATE()、YEAR()、MONTH()、DAY() 等原生日期函数做计算，它们在某些条件下可走索引（尤其是配合范围查询时）；格式化只留在 SELECT 列表里。
时区陷阱：NOW() vs UTC_TIMESTAMP()，以及字段类型的影响
如果 MySQL 服务器时区和业务时区不一致（比如服务器设为 UTC，但业务按北京时间运营），NOW() 返回的是服务器本地时间，会导致「本周」「本月」算错。
关键点：
- 确认 MySQL 时区：
SELECT @@time_zone, @@system_time_zone; - 如果业务统一用东八区，且不能改服务器配置，建议用
CONVERT_TZ(NOW(), '+00:00', '+08:00')替代NOW() - 更稳妥做法：所有时间字段存 UTC（
TIMESTAMP类型默认按 UTC 存储），查询时显式转换：WHERE create_time >= CONVERT_TZ('2024-05-20 00:00:00', '+08:00', '+00:00') -
DATETIME类型不自动时区转换，TIMESTAMP类型读写都会转为当前会话时区——这点常被忽略，导致同一条 SQL 在不同连接里结果不一致
跨时区业务里，YEARWEEK() 和 LAST_DAY() 这类函数的输入时间值是否已对齐业务时区，比函数本身怎么写更重要。
