接触过 MySQL 的同学，基本都跟字符串形式的日期打过交道。业务报表、第三方接口、Excel 导入导出、日志清洗……“MySQL 字符串日期格式转换”这组关键词，几乎每天都能在工单和讨论群里看到一轮。很多开发第一反应是DATE_FORMAT一把梭，结果等到要拿字符串去过滤、去排序、去分组的时候，又开始被结果搞晕：为什么一样的写法，有的库能跑，有的库查出来是 NULL？为什么明明建了索引，查询计划还是不走？这些问题的根子，大多出在“字符串日期”和“真正的日期类型”之间的那道边界上。
这篇文章我不打算罗列函数手册，而是结合我这些年处理过的真实场景，把字符串日期转换的前因后果、函数选择、隐式转换的坑、非法日期的表现、以及查询性能的影响一次讲透。适合正在写数据同步脚本的后端开发、经常做报表的数据分析、维护老系统的 DBA，以及所有被“日期格式不统一”折磨过的人。
1. 业务里的日期字符串，为什么总是不按套路出牌
1.1 五花八门的真实来源
先说我在实际项目里见过的几种典型日期字符串形态。
第一种是接口对接。第三方系统传过来的时间字段，有的长这样：2024-06-01 14:23:45，带完整时分秒；有的只有一天粒度：2024-06-01；更狠的还有20240601这种八位纯数字。同一个字段，因为上游发版迭代过几次，老数据和新数据格式居然还不一样。
第二种是 Excel 导入。运营同学导进来的表格里，日期列的表现形式更是百花齐放：2024/6/1、6/1/2024、01-Jun-2024、甚至还有被 Excel 自动识别成序列号的45444这种数字。数据落库之后如果原样存进 VARCHAR 字段，后面做任何统计分析都是灾难。
第三种是日志文件。服务端日志里的时间戳通常是2024-06-01T14:23:45.000Z这种 ISO8601 格式，带T和毫秒，最后还跟着时区标识。而业务库里的标准日期字段根本不吃这一套，必须转换后才能写入。
这些场景如果只是“显示一下”，那无所谓，字符串原样透出就行。但只要涉及排序、范围查询、按天分组、月环比计算，字符串和日期类型的行为差异就会被无限放大。字符串排序是字典序，'2024-01-31'会排在'2024-02-01'后面没问题，但'2024-6-1'这种不带前导零的格式，字典序就会把'2024-10-1'排到'2024-6-1'前面——因为'1'小于'6'。这种反直觉的结果，不知道坑了多少人的报表数据。
1.2 先分清日期字符串的“阵营”
面对一堆字符串日期，第一步不是急着写转换函数，而是先分类。我习惯把它们分成三组：
- 标准可识别格式：
2024-06-01、2024-06-01 14:23:45、2024-06-01T14:23:45。这些格式 MySQL 的CAST和比较运算符能直接识别，不需要额外的格式说明。 - 非标准分隔符格式：
2024/06/01、20240601、01-06-2024。这里面有的隐含歧义（月日顺序），有的需要显式告诉 MySQL 怎么解析。 - 带时区或带毫秒的复杂格式：
2024-06-01T14:23:45.000Z、2024-06-01 14:23:45 +08:00。这类处理起来最麻烦，往往需要先做字符串预处理，再进入日期转换流程。
把这个分类搞清楚了，后面选函数心里就有底。标准格式用轻量方案，非标准格式上STR_TO_DATE，复杂格式先预处理再用组合拳。这是所有字符串日期转换工作的总纲。
2. STR_TO_DATE 与 DATE_FORMAT：一对互为镜像的钥匙
2.1 STR_TO_DATE：把字符串“翻译”成日期
STR_TO_DATE(str, format)是字符串日期转换的核心工具。它的工作逻辑非常直白：你告诉它输入字符串长什么样，它按照这个模板去解析，最终产出一个 DATETIME 类型的值。
看几个我最常用的例子：
-- 标准日期时间 SELECT STR_TO_DATE('2024-06-01 14:23:45', '%Y-%m-%d %H:%i:%s'); -- 结果：2024-06-01 14:23:45 -- 斜杠分隔的日期 SELECT STR_TO_DATE('2024/06/01', '%Y/%m/%d'); -- 结果：2024-06-01 -- 八位纯数字 SELECT STR_TO_DATE('20240601', '%Y%m%d'); -- 结果：2024-06-01 -- 带毫秒的时间戳（截断毫秒） SELECT STR_TO_DATE('2024-06-01 14:23:45.123', '%Y-%m-%d %H:%i:%s'); -- 结果：2024-06-01 14:23:45（毫秒部分被忽略）这里需要重点记住格式符的含义，因为%后面跟的字符不同，解析结果天差地别：
| 格式符 | 含义 | 示例输入 | 解析结果 |
|---|---|---|---|
%Y | 四位年份 | 2024 | 2024 |
%y | 两位年份（00-69 映射到 2000-2069，70-99 映射到 1970-1999） | 24 | 2024 |
%m | 两位月份（01-12） | 06 | 06 |
%c | 月份（1-12，无前导零） | 6 | 6 |
%d | 两位日（01-31） | 01 | 01 |
%e | 日（1-31，无前导零） | 1 | 1 |
%H | 24小时制小时（00-23） | 14 | 14 |
%k | 24小时制小时（0-23，无前导零） | 14 | 14 |
%i | 分钟（00-59） | 23 | 23 |
%s | 秒（00-59） | 45 | 45 |
%f | 微秒（000000-999999） | 123456 | 123456 |
%p | AM 或 PM | PM | PM |
%r | 12小时制时间（hh:mm:ss AM/PM） | 02:23:45 PM | 14:23:45 |
%T | 24小时制时间（hh:mm:ss） | 14:23:45 | 14:23:45 |
%W | 星期名称（Sunday-Saturday） | Saturday | NULL（若不匹配实际星期） |
%a | 星期缩写（Sun-Sat） | Sat | NULL |
%M | 月份名称（January-December） | June | 06 |
%b | 月份缩写（Jan-Dec） | Jun | 06 |
一个最经典的坑就是%d和%e。如果输入的字符串是2024-6-1，也就是月份和日都没有前导零，你用%Y-%m-%d去解析，结果是 NULL。因为%m和%d严格要求两位，单数字的时候必须改用%c和%e：
SELECT STR_TO_DATE('2024-6-1', '%Y-%c-%e'); -- 结果：2024-06-01这个细节我在实际工单里至少看到过三次：开发同学线上数据是2024-6-1这种格式导入失败，排查到最后就是格式符不匹配。
2.2 DATE_FORMAT：把日期“翻译”回字符串
DATE_FORMAT(date, format)是STR_TO_DATE的反向操作。它接收一个真正的日期/时间类型，按照格式输出字符串。它的主要使用场景不是清洗数据，而是“展示格式化”和“分组键格式化”。
SELECT DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:%s'); -- 输出：2024-06-01 14:23:45 SELECT DATE_FORMAT(NOW(), '%Y年%m月%d日'); -- 输出：2024年06月01日 SELECT DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i'); -- 输出：2024-06-01 14:23注意，DATE_FORMAT返回的是字符串，不是日期类型。所以如果你把它用在WHERE条件里和另一个日期字段比较，MySQL 会尝试把那个日期字段也转成字符串来做比较。具体表现和隐式转换规则有关，后面第4章会展开讲。
另外还有一对容易被混淆的函数：STR_TO_DATE和DATE_FORMAT虽然格式符体系一致，但它们的底层实现完全不同：一个是解析器，一个是格式化器。你完全可以用相同的一套格式符，“一个负责进、一个负责出”，这也是为什么我说它们是“互为镜像的钥匙”。
2.3 CAST 和 CONVERT：轻量场景的快捷方式
如果你的字符串已经是 MySQL 能直接识别的标准格式，比如2024-06-01或2024-06-01 14:23:45，那没必要动用STR_TO_DATE，直接用CAST更简洁：
SELECT CAST('2024-06-01' AS DATE); -- 结果：2024-06-01 00:00:00，类型是 DATE SELECT CAST('2024-06-01 14:23:45' AS DATETIME); -- 结果：2024-06-01 14:23:45 SELECT CONVERT('2024-06-01 14:23:45', DATETIME); -- 结果：2024-06-01 14:23:45CAST和CONVERT在这个场景下的行为基本一致。关键知识点在于：MySQL 对标准格式的识别范围很广。20240601这种八位数字其实也能被直接CAST成日期：
SELECT CAST('20240601' AS DATE); -- 结果：2024-06-01这让很多人吃惊，但确实如此。MySQL 的日期解析器对于没有分隔符的数字串有一套自动识别逻辑，YYYYMMDD模式能被正确解析。不过我必须提醒一句：虽然能用，但别依赖这个特性。代码的可读性和团队协作中，“显式优于隐式”永远是第一原则。如果你在维护一个多人参与的项目，让别人看懂你在转换什么格式，比省几个字符重要得多。
3. 实战拆解：从账单导入到报表输出的转换全链路
3.1 场景设定与建表
我用一个真实的业务场景把整套转换串起来：假设我们有一个老系统导出的账单文件，里面的日期字段可能是2024/06/01、2024-6-1甚至20240601的混合体，需要导入到新库进行分析。
新建表：
CREATE TABLE bill ( id INT PRIMARY KEY AUTO_INCREMENT, bill_no VARCHAR(32), occurred_at DATETIME NOT NULL, amount DECIMAL(10, 2), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );这里把业务时间列设成DATETIME，而不是VARCHAR，是刻意为之：日期类型才能做真正的范围查询、日期间隔计算和索引优化。
3.2 导入阶段的清洗策略
导入时如果直接INSERT，遇到2024/06/01这种字符串，MySQL 虽然能兼容一部分带分隔符的格式，但2024-6-1这种无前导零的格式大概率会被解析成 0（也就是0000-00-00），甚至在有严格模式的数据库里直接报错中断。
所以稳妥的做法是先用STR_TO_DATE统一清洗：
INSERT INTO bill (bill_no, occurred_at, amount) SELECT bill_no, STR_TO_DATE( CASE WHEN date_str LIKE '%/%' THEN REPLACE(date_str, '/', '-') ELSE date_str END, '%Y-%m-%d %H:%i:%s' ), amount FROM temp_import;这里用CASE做了一步预处理：把斜杠分隔符替换成短横线，然后统一交给STR_TO_DATE解析。为什么不直接用%Y/%m/%d？因为同一个字段里还有可能是2024-6-1这种没有前导零的格式，%d匹配不了1。最省心的办法是先把分隔符统一成短横线，再用%c和%e去兼容单数字。我自己在写清洗脚本的时候，经常用REPLACE先做“格式归一化”，把各种分隔符统一，再交给STR_TO_DATE收口。这样格式符的维护成本小很多。
如果原始数据里混进空字符串，别直接丢给STR_TO_DATE，先判断空值：
INSERT INTO bill (bill_no, occurred_at, amount) SELECT bill_no, CASE WHEN date_str IS NULL OR date_str = '' THEN NULL ELSE STR_TO_DATE(REPLACE(date_str, '/', '-'), '%Y-%m-%d %H:%i:%s') END, amount FROM temp_import;把无法解析的脏数据变成NULL，总比导入中断强。业务上可以通过后续WHERE occurred_at IS NULL快速定位脏数据。
3.3 查询阶段的格式化输出
数据落库之后，查询端的需求往往是“把日期格式化成业务想要的样式”。比如账单列表页要显示成2024年06月01日，月度报表要按YYYY-MM分组：
SELECT bill_no, DATE_FORMAT(occurred_at, '%Y年%m月%d日') AS show_date, amount FROM bill WHERE occurred_at >= '2024-06-01' AND occurred_at < '2024-07-01';按月份分组统计：
SELECT DATE_FORMAT(occurred_at, '%Y-%m') AS month, SUM(amount) AS total_amount FROM bill WHERE occurred_at >= '2024-01-01' AND occurred_at < '2025-01-01' GROUP BY DATE_FORMAT(occurred_at, '%Y-%m') ORDER BY month;这里有一个非常重要的实操点：GROUP BY后面可以直接用DATE_FORMAT(occurred_at, '%Y-%m')，也可以用别名month。MySQL 在GROUP BY中允许引用SELECT列表里的别名，但为了让 SQL 更严谨可移植，很多团队规范强制要求GROUP BY中写完整表达式。我个人的习惯是：小查询用别名提升可读性，复杂查询写全表达式避免歧义。
3.4 字符串条件过滤的隐患
报表系统常见的一个错误写法是，日期字段在入库时被存成了 VARCHAR，然后查询端用字符串去过滤：
SELECT * FROM bill WHERE date_str BETWEEN '2024-06-01' AND '2024-06-30';如果date_str里的格式是统一的YYYY-MM-DD，这个写法碰巧能用，因为字典序和日期序一致。但如果里面混了2024-6-1这样的数据，字符串比较就会漏数据。正确的做法是查询之前先把字符串列转换成日期：
SELECT * FROM bill WHERE STR_TO_DATE(date_str, '%Y-%m-%d') BETWEEN '2024-06-01' AND '2024-06-30';但注意，这个写法在索引上吃大亏——STR_TO_DATE(date_str, ...)包裹了列，索引直接失效。后面第4章我会专门讲这个问题。
4. 隐式转换：最容易翻车的“自动好心”
4.1 隐式转换规则
MySQL 在比较不同类型值时，会自动做类型转换，这在官方文档里叫“隐式转换”。字符串和日期/数字比较时，规则大体是：如果两边都是字符串，按字符串比较；如果一边是字符串、一边是数字，字符串转数字；如果一边是字符串、一边是日期，取决于字符串是否能在上下文中被识别为日期。
听起来没什么，但实际踩坑场景非常多。先说一个最常见的：字符串列和日期字面量比较。
SELECT * FROM bill WHERE date_str = '2024-06-01';这里date_str是 VARCHAR，'2024-06-01'也是字符串，两边都按字符串比较，看起来没问题。但如果你写成：
SELECT * FROM bill WHERE date_str = '2024-6-1';字符串'2024-06-01'和'2024-6-1'字典序不同，结果什么都查不到。而如果date_str是 DATE 类型，MySQL 会尝试把'2024-6-1'解析成日期，然后和日期值比较，反而能匹配上。同一个 SQL 写法，因为列类型不同，结果完全不一样。
另一个经典翻车现场，是把 DATE 类型列和带空格/不带空格的字符串比较：
SELECT * FROM bill WHERE occurred_at = '2024-06-01';occurred_at是DATETIME，它实际存储的是2024-06-01 00:00:00。字符串'2024-06-01'在比较时会被自动补成'2024-06-01 00:00:00'再比较，所以这个查询能查到当天零点整的数据。但如果你写的字符串带上了时分秒，比如'2024-06-01 12:00:00'，那它就只匹配那一个时间点。很多人写“查某天数据”时踩坑，就是因为他们以为传一个日期就能匹配整天，实际上 MySQL 严格按时间点匹配，必须自己补范围。
4.2 典型事故现场：索引失效
隐式转换最痛的代价是索引失效。MySQL 在列上应用函数时，查询优化器通常无法使用该列上的普通索引。看一个实际案例：
假设我们在occurred_at上建了索引：
ALTER TABLE bill ADD INDEX idx_occurred_at (occurred_at);如果查询写成：
SELECT * FROM bill WHERE DATE_FORMAT(occurred_at, '%Y-%m-%d') = '2024-06-01';这种写法无论是性能还是可读性都是灾难。优化器对DATE_FORMAT(occurred_at, ...)这种表达式无法直接下推索引条件，只能全表扫描。正确的写法是直接用日期范围：
SELECT * FROM bill WHERE occurred_at >= '2024-06-01 00:00:00' AND occurred_at < '2024-06-02 00:00:00';如果一定要按天查询，不要对列做函数处理，而是对“查询条件”做变换。这是一个几乎所有人刚开始都会犯的错误：为了匹配格式，去给列套函数；实际应该反过来，给字面量做适配。
还有一类更隐蔽的隐式转换，发生在字符集或排序规则不一致时。比如被转换的字符串列和常量是不同 collation，MySQL 会把一边转成另一边再比较，这个过程也可能导致索引失效。排查这类问题，基本手段就是看EXPLAIN的type字段：如果是ALL，基本就是在全表扫描了。
4.3 用 EXPLAIN 验证转换对执行计划的影响
我每次怀疑索引被日期转换干掉的时候，都会跑一遍EXPLAIN验证：
EXPLAIN SELECT * FROM bill WHERE occurred_at >= '2024-06-01' AND occurred_at < '2024-06-02';正常应该看到type=range，key=idx_occurred_at。如果看到type=ALL，说明优化器没走索引。再换一个带函数的写法对比：
EXPLAIN SELECT * FROM bill WHERE DATE_FORMAT(occurred_at, '%Y-%m-%d') = '2024-06-01';后者通常就是type=ALL。这个对比在排查性能问题时很有说服力，建议直接发给开发同学，比口头解释一百句都有效。
还有一个容易被忽略的隐式转换：当 VARCHAR 列存的是数字，和数字比较时会全部转成数字再比。比如某订单表order_code列存了'1001'，查询用WHERE order_code = 1001，MySQL 会把每个order_code都转成数字，一旦有非数字字符就变成 0，索引也废了。日期转换问题也是同样的原理：让列去做“额外动作”，就必然付出性能代价。
5. 非法日期、时区与 NULL：三个隐藏深水区
5.1 2024-02-30 到底怎么处理
字符串日期转换最容易出“看似成功、实则失败”的场景，就是非法日期。比如2024-02-30在逻辑上根本不存在，但如果你用STR_TO_DATE去解析：
SELECT STR_TO_DATE('2024-02-30', '%Y-%m-%d');在不同sql_mode下结果完全不同。在默认sql_mode下，MySQL 会返回 NULL。如果数据库设置为ALLOW_INVALID_DATES，它可能直接返回2024-02-30，虽然这个日期不合法。更闹鬼的是，在某些版本下STR_TO_DATE('2024-02-30', '%Y-%m-%d')会把日期“进位”成2024-03-01——别怀疑，我确实在线上看到过这种结果。
为什么会有这种差异？因为 MySQL 的日期解析器在宽松模式下，对超出范围的天数做“溢出进位处理”。这种行为的危害在于：数据被静默篡改，上游脏数据不会报错，而是以错误的合法日期落库。等到月底对账的时候，你根本想不到问题出在一个“被进位”的日期上。
所以在清洗脚本里，强烈建议对转换结果做一次回验：
SELECT original_str, STR_TO_DATE(original_str, '%Y-%m-%d') AS converted_date, CASE WHEN STR_TO_DATE(original_str, '%Y-%m-%d') IS NULL AND original_str IS NOT NULL AND original_str != '' THEN '非法日期' END AS check_result FROM temp_import;如果发现 NULL 或非法日期，集中输出到一个异常表里人工处理，而不是放任它静默通过。正确处理非法日期的第一步，是先在源头把它识别出来。
5.2 SQL Mode 对日期转换的影响
数据库的sql_mode参数影响非常大。重点看三个：
STRICT_TRANS_TABLES：严格模式。插入非法日期直接报错，拒绝执行。ALLOW_INVALID_DATES：宽容模式。接受非法日期，比如2024-02-30会存储为字面值，后续读取还是那个值，但做日期运算时行为不可预期。NO_ZERO_DATE/NO_ZERO_IN_DATE：不允许0000-00-00或者月份的00。
查看当前模式：
SELECT @@sql_mode;我接触过的生产环境里，MySQL 8.0 的默认sql_mode是STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO，这种组合下非法日期基本会直接报错。但这不代表安全——因为很多老系统是从 MySQL 5.6 一路升级过来的，sql_mode千奇百怪，有的甚至允许0000-00-00长期存在。
这里有个很实用的建议：如果你们的业务不允许非法日期，尽量保持严格模式，让数据在入口被拦住，好过入库之后到处救火。如果历史原因导致库里已经存在0000-00-00，那在查询阶段要用IF或CASE做防御性判断：
SELECT bill_no, CASE WHEN occurred_at = '0000-00-00' OR occurred_at IS NULL THEN '1990-01-01' ELSE DATE_FORMAT(occurred_at, '%Y-%m-%d') END AS safe_date FROM bill;注意，对DATE类型直接比较'0000-00-00'在有些模式下面会告警甚至报错，最好在查询前先用CAST或IFNULL兜底，不要依赖数据库的安静行为。
5.3 时区与 TIMESTAMP/DATETIME 选择
严格来说时区不属于“字符串格式转换”，但字符串日期里一旦带时区标识，就会和转换纠缠在一起。比如上游传来2024-06-01T14:23:45.000Z，这个Z代表 UTC 时间。如果直接STR_TO_DATE('2024-06-01T14:23:45.000Z', '%Y-%m-%dT%H:%i:%s.%f')，虽然能把2024-06-01 14:23:45解析出来，但这个值其实是 UTC 时间，不是你所在业务时区的本地时间。
先做时区偏移预处理，再转换。比如目标时区是 UTC+8，就按 8 小时加到解析前的原始字符串上；或者先解析成时间戳，再加偏移。具体要看业务统一口径。如果业务只要求显示，直接忽略毫秒和时区标识、只取前半段也可以，但做统计的时候必须保持同口径。
另外，TIMESTAMP类型在存储时会根据time_zone参数做转换，而DATETIME不会。如果你们的服务端和数据库不在同一个时区，插入带时间的字符串一定要清楚这个差异。比如服务器时区是 UTC，你INSERT一个'2024-06-01 14:23:45'字符串到TIMESTAMP列，数据库会认为是 UTC 时间并转成内部存储值；读取时再转回你设置的会话时区，结果就可能和你本地看到的差好几小时。这种情况下，最稳妥的做法是应用层先统一成业务标准时区的日期字符串，再交给数据库，别依赖数据库自动转换。
5.4 NULL 默认值处理
字符串日期转换时遇到 NULL 是家常便饭。这里有三种情况要区分：
- 原始字符串就是 NULL：还没进入转换，直接保留 NULL。
- 原始字符串是空字符串
''：在 MySQL 里''转日期会得到0000-00-00，但严格模式下可能报错。 - 原始字符串格式不匹配：转换结果是 NULL，但原始值非空。
这三种情况在实际排查时表现完全不一样。很多开发写转换时只判断了第一种，导致空字符串变成1970-01-01或0000-00-00混进库里。我用的一个比较规范的清洗模板是：
SELECT CASE WHEN date_str IS NULL THEN NULL WHEN date_str = '' THEN NULL WHEN STR_TO_DATE(date_str, '%Y-%m-%d %H:%i:%s') IS NULL THEN NULL ELSE STR_TO_DATE(date_str, '%Y-%m-%d %H:%i:%s') END AS cleaned_date FROM temp_import;有经验的同学会发现，这段 SQL 里STR_TO_DATE被写了两次。如果你特别在意查询可读性，可以先在子查询里算一次：
SELECT CASE WHEN date_str IS NULL OR date_str = '' OR parsed_date IS NULL THEN NULL ELSE parsed_date END AS cleaned_date FROM ( SELECT date_str, STR_TO_DATE(date_str, '%Y-%m-%d %H:%i:%s') AS parsed_date FROM temp_import ) t;两种写法都能用，第一种更适合临时清洗脚本，第二种更适合写进定时任务。
6. 工程建议：转换逻辑放 SQL 层还是应用层？
6.1 不同场景的取舍
字符串日期转换到底该在 SQL 里做，还是在应用代码里做？这问题没有标准答案，取决于使用场景。
我的经验是这样划分的：
- 数据导入/清洗阶段：优先在 SQL/ETL 层做转换。因为数据量通常大，应用层一条条处理性能差，而且 ETL 脚本可以方便地重跑、回放、对比。
- 联机查询（OLTP）阶段：尽量避免在 SQL 里对列做转换。应该在建表时就把数据存成正确的日期类型，查询时用参数范围去过滤。如果必须在 SQL 里格式化输出，用
DATE_FORMAT没问题，但别把它用在WHERE条件里。 - 报表查询（OLAP）阶段：
DATE_FORMAT做分组键是常规操作，但要评估数据量和执行时间。如果表很大，可以考虑在数仓层先加工成YYYY-MM-01这种“月起始日期”，用真正的日期类型存储，比在查询时格式化再分组快得多。
本质上，这是一个“数据在哪里被加工”的战略问题。我的原则是：能让数据在写入时变成正确类型的地方，绝不留到查询时再转换。查询时每多一次转换，就多一分出错可能，也多一分索引失效风险。
6.2 按天查询的正确写法
结合上面所有技术点，给出一个“标准答案”式的按天查询模板：
-- 正确：传入日期参数，自动扩散成整天范围 SELECT DATE_FORMAT(occurred_at, '%Y-%m-%d') AS day, COUNT(*) AS cnt, SUM(amount) AS total FROM bill WHERE occurred_at >= '2024-06-01 00:00:00' AND occurred_at < '2024-06-02 00:00:00' GROUP BY DATE_FORMAT(occurred_at, '%Y-%m-%d');如果是在 Java/Go 这类应用代码里拼 SQL，很多团队直接用：
WHERE occurred_at >= ? AND occurred_at < DATE_ADD(?, INTERVAL 1 DAY)这样写的好处是，应用层传一个2024-06-01参数，数据库自动算出第二天的边界，索引也能正常走。
另外还有个小技巧：如果你要查的是“今天”的数据，别在 SQL 里写死'2024-06-01'，用CURDATE()或CURRENT_DATE动态生成：
WHERE occurred_at >= CURDATE() AND occurred_at < CURDATE() + INTERVAL 1 DAY这样脚本每天跑都正确，不用改参数。
6.3 我给新接触这个主题的同学的清单
最后把我这些年做字符串日期转换总结出的经验，浓缩成一份可直接照做的清单：
- 建表时日期字段必须用 DATE/DATETIME/TIMESTAMP，不要用 VARCHAR 存日期。
- 数据导入阶段用
STR_TO_DATE配合CASE做清洗，对 NULL、空串、非法格式分别处理。 - 清洗脚本里补一个“回验”步骤，把转换后仍然为 NULL 或怪异日期的记录单独导出。
- 查询过滤时不要对日期列套函数，改成对查询值做范围变换。
- 需要在报表里把日期显示成特定格式时，用
DATE_FORMAT，但只在SELECT列表和GROUP BY中使用。 - 遇到字符串日期比较的奇怪结果，先看两边的数据类型，再用
SELECT CAST(...)手动验证。 - 生产环境保持严格的
sql_mode，宁可导入报错也不要静默修改数据。 - 时区相关业务，统一在应用层转换成业务标准时区的日期字符串，再交给数据库。
这套清单支撑我处理过不少“日期混乱”的历史库迁移。有一次某运营系统的历史数据里混了三套日期格式，总共几百万行，我按这套流程写了临时清洗脚本，先做格式归一化，再STR_TO_DATE转换，然后回验非法日期，最后把异常数据单独导出人工核对。整个过程没有出现任何一条数据被静默改写的情况。那次之后我就坚信：日期转换不是“写个函数调一下”那么简单，它是一条需要认真设计的数据管道。
字符串日期转换这件事，表面看是函数用法问题，实际是数据管道的质量关卡。把上面这些细节理清楚、在代码里形成规范，你就能少踩很多“看起来没问题、跑起来全不对”的坑。
