用 DATE_FORMAT(NOW(), '%Y-%m-%d') 可将时间转为“2024-03-15”格式，%Y、%m、%d 分别表示4位年、补零月、补零日；VARCHAR 日期需先用 STR_TO_DATE 转换；注意时区与索引失效问题。
MySQL 里 DATE_FORMAT 怎么把时间转成“2024-03-15”这种格式？
DATE_FORMAT 不是格式化任意字符串，它只吃合法的日期时间值（比如 NOW()、created_at 字段），传进去 '2024/03/15' 这种字符串会静默转成 0000-00-00，不报错但结果错得离谱。
- 想要“年-月-日”，用
DATE_FORMAT(NOW(), '%Y-%m-%d')，%Y是 4 位年份，%m是补零月，%d是补零日 - 别用
%y（两位年份）或%c（不补零月），否则可能得到24-3-5这种不一致输出 - 如果字段本身是
DATE类型（如order_date），直接DATE_FORMAT(order_date, '%Y-%m-%d')就行；如果是VARCHAR存的日期，先用STR_TO_DATE(order_date, '%Y/%m/%d')转成日期再格式化
NOW() 返回的时间不准？时区没对上
NOW() 返回的是 MySQL 服务端当前时区的时间，不是你本地电脑时区，也不是 PHP 或 Python 应用所在的时区。常见现象是：PHP 里 date('Y-m-d H:i:s') 和 SQL 里 NOW() 差 8 小时。
- 查看 MySQL 当前时区：
SELECT @@time_zone;，返回SYSTEM表示跟随系统，返回+08:00才是东八区 - 临时改会话时区：
SET time_zone = '+08:00';，但下次连接就失效 - 永久生效要改 MySQL 配置文件
my.cnf的default-time-zone='+08:00'，然后重启 mysqld - 如果应用层已统一用 UTC 存储，别在 SQL 里硬套
NOW()，改用UTC_TIMESTAMP()更可控
用 DATE_FORMAT 做 WHERE 条件，为什么索引失效？
WHERE DATE_FORMAT(created_at, '%Y-%m') = '2024-03' 看起来直观，但会让 created_at 字段上的索引完全失效，哪怕数据量一两万，查询也会变慢。
- 原因：函数作用于字段，MySQL 无法用索引做范围扫描，只能全表扫描
- 正确写法是把函数移到右边：
WHERE created_at >= '2024-03-01' AND created_at < '2024-04-01' - 如果必须按“年月”查且字段是
DATETIME，可建生成列索引：ALTER TABLE logs ADD COLUMN ym CHAR(7) GENERATED ALWAYS AS (DATE_FORMAT(created_at, '%Y-%m')) STORED;，再给ym加索引 - 注意
STORED是必须的，VIRTUAL列不能建索引
跨数据库移植时，DATE_FORMAT 和 NOW() 兼容性差在哪？
DATE_FORMAT 和 NOW() 是 MySQL 特有语法，PostgreSQL、SQL Server、SQLite 都不认。想写一次 SQL 跑多库？基本不可能。
- PostgreSQL 对应的是
TO_CHAR(NOW(), 'YYYY-MM-DD')和NOW()（但返回TIMESTAMP WITH TIME ZONE） - SQL Server 用
FORMAT(GETDATE(), 'yyyy-MM-dd')，但性能差，推荐CONVERT(VARCHAR, GETDATE(), 23) - SQLite 只有
strftime('%Y-%m-%d', 'now')，NOW()直接报错 - 如果项目真要兼容多库，日期处理尽量下推到应用层，SQL 层只传 ISO 格式字符串（如
'2024-03-15T09:30:00'），避免依赖数据库函数
时区和索引这两块最容易被忽略，尤其上线后数据量涨上来，慢查询往往就栽在这两个点上。
