最近在做运营后台的统计需求时前端抛过来两个字符串时间参数startTime2024-01-01、endTime2024-01-31让我按订单创建时间查一段区间内的数据。项目用的是 MyBatis-Plus我第一反应就是写个 LambdaQueryWrapper把字符串直接塞进 ge 里。页面一刷新数据就是不对。排查到最后发现字符串时间格式查询这件事远比表面看起来复杂。这个坑其实非常典型几乎每个用 MyBatis-Plus 做过时间范围查询的人都会撞上。这篇就把「字符串时间格式查询」从原理到实操摊开讲清楚包含为什么字符串能直接查、什么时候必须转类型、五种常用写法怎么选、某一天查询的临界值边界怎么算以及时区、格式、索引失效这些实战中常见的坑。1. 场景还原为什么会有字符串时间查询这种需求1.1 字符串时间的两个主要来源我见过的大部分时间查询参数都不是 Date 或 LocalDateTime而是字符串。最常见的有两类场景。第一类是前端组件直接传值。Vue 项目里的 el-date-picker、Ant Design 的 DatePicker、laydate 这些组件如果没做值格式化提交给后端的默认值就是 2024-01-15 或者 2024-01-15 10:30:00 这种字符串。后端接口如果用 String 接收那这些字符串就直接进了 Mapper。第二类是历史遗留表字段本身就是 VARCHAR 类型。比如几年前设计的流水表create_time 字段是 varchar(32)存的就是 2024-01-15 10:30:00。这种情况下数据库里根本没有日期类型不管你用什么 ORM最终执行的 SQL 都是字符串匹配。这两类场景看起来都要做字符串时间查询但背后的处理逻辑完全不一样。前者是字符串和日期类型做比较需要依赖数据库的隐式转换后者是字符串和字符串做比较纯粹是字典序匹配。很多人没分清这两者导致 SQL 写出去不是查不到就是结果多出几条。1.2 数据库层的隐式转换到底做了什么先看 MySQL 的处理逻辑。当你有一个 datetime 类型的字段 create_time执行 WHERE create_time 2024-01-01 时MySQL 并不会直接比较字符串和日期而是把 2024-01-01 转成一个合法的日期时间值再和 create_time 对比。这个转换规则在意料之中但也最容易出问题。比如字符串是 2024-01-01MySQL 会把它解析成 2024-01-01 00:00:00。此时用 去查可以查出 1 号零点之后的所有数据。但如果字符串是 2024-01-01 10:00:00而你拿它去和 date 类型字段比较date 字段会先转成 datetime即 2024-01-01 00:00:00再和字符串值比较两者就不相等。用 查询时当天 10 点之后的数据永远匹配不上。这里有个生活化的类比你把一个写好了收件门牌号的快递单交给快递员快递员的系统里也有一份门牌号记录。只要两边门牌号格式一致就能正常投递格式一旦不一致哪怕指向同一个位置系统也认不出来。所以在 MyBatis-Plus 里写查询前先搞清楚你的字符串会被数据库如何解析是第一步。这决定了你要用 、、、BETWEEN 还是 DATE_FORMAT 函数。2. 五种写法对比从直接比较到封装工具类2.1 粗暴型字符串直接塞进 Wrapper最直接的方式是这样的LambdaQueryWrapperOrderEntity wrapper Wrappers.lambdaQuery(); wrapper.ge(OrderEntity::getCreateTime, 2024-01-01) .le(OrderEntity::getCreateTime, 2024-01-31); ListOrderEntity list orderMapper.selectList(wrapper);这种方式能不能跑通能。前提是数据库的 create_time 字段是 datetime而你传入的字符串刚好是 MySQL 能识别的标准格式。MySQL 会把这两个字符串转成 datetime执行结果基本符合预期。但隐患也很明显。第一字符串格式一旦变成 2024/01/01 或 20240101隐式转换规则就会变得不可控可能直接报错也可能查不出数据。第二如果 create_time 字段恰好是 VARCHAR那这条 SQL 就变成了字符串字典序比较2024-01-31 和 2024-2-1 这种值会排在完全不同的位置查询结果极其容易漏数据。我的建议是写 Demo 可以这么玩生产代码里尽量别直接用。2.2 推荐型Service 层转成 LocalDateTime这个方案是我最常用的也是我认为最稳的接口接收 String在 Service 层用 DateTimeFormatter 解析成 LocalDateTime再传给 Wrapper。DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); LocalDateTime start LocalDateTime.parse(2024-01-01 00:00:00, formatter); LocalDateTime end LocalDateTime.parse(2024-01-31 23:59:59, formatter); LambdaQueryWrapperOrderEntity wrapper Wrappers.lambdaQuery(); wrapper.ge(OrderEntity::getCreateTime, start) .le(OrderEntity::getCreateTime, end);这样做的优势在于Java 层已经帮你完成了字符串合法性的校验格式不对会在 parse 阶段直接抛异常而不是等到 SQL 执行时才暴露。同时传给数据库的是真正的日期时间对象MyBatis-Plus 会使用类型处理器把 LocalDateTime 转成 JDBC 需要的 Timestamp不依赖 MySQL 的隐式转换语义清晰。如果你用的是 JDK 8 之前的项目也可以用 SimpleDateFormat 转成 java.util.Date效果一样。2.3 取巧型数据库函数配合字符串还有一部分人会这么写wrapper.apply(DATE_FORMAT(create_time, %Y-%m-%d) {0}, 2024-01-15);这个写法能精确匹配某一天字符串格式也非常灵活只要和格式化模板一致即可。但我强烈不建议在查询条件里这么干核心原因是索引会失效。create_time 字段上如果建了索引一旦在 WHERE 条件里用 DATE_FORMAT 将它包起来MySQL 就无法使用该索引只能全表扫描。数据量小没事数据量到了千万级这条 SQL 直接拖垮数据库。2.4 区间型Between 解决某一天查询查询某一天的数据很多人都想用 betweenwrapper.between(OrderEntity::getCreateTime, 2024-01-15 00:00:00, 2024-01-15 23:59:59);这个写法逻辑上没错边界也理解对了。但它有个隐蔽的坑如果字符串格式里带了毫秒或 23:59:59.999而数据库存储的时间包含微秒边界值就可能会丢数据。更稳妥的写法是左闭右开区间wrapper.ge(OrderEntity::getCreateTime, 2024-01-15 00:00:00) .lt(OrderEntity::getCreateTime, 2024-01-16 00:00:00);用 lt 包住第二天零点比用 le 传当天 23:59:59更安全。因为那一天最后一秒可能是 23:59:59.5也可能有微秒值直接 le 23:59:59 会把 23:59:59.500 这种数据挡在门外。2.5 兜底型apply 自定义条件片段如果查询逻辑实在复杂比如要传一个函数表达式、要按周查询、要按季度查询LambdaQueryWrapper 自带的条件可能不够用。这时可以用 apply 写自定义 SQL 片段wrapper.apply(create_time STR_TO_DATE({0}, %Y-%m-%d), 2024-01-15);注意 apply 里的 {0} 是占位符MyBatis-Plus 会把它替换成参数占位符 ?而不是直接拼接字符串。这能有效防止 SQL 注入。千万不要自己用字符串拼接把用户输入直接写进条件里那是安全大忌。我把这五种方案的取舍整理成了一张表方案适用场景优点必须注意的坑直接塞字符串临时排查数据代码最少写法直观依赖隐式转换格式稍有不符就出问题Service 转 LocalDateTime日常业务查询类型安全格式校验在前可读性强需要多写几行解析代码DATE_FORMAT 函数不需要走索引的小表查询格式匹配灵活索引失效数据量大时慢查询Between / gelt 区间查询某一天或固定范围边界清晰索引友好边界值要仔细计算apply 自定义片段复杂表达式或函数查询灵活可控性强必须用占位符防注入实际选择时我的原则很简单常规查询优先方案二固定某一天优先方案四特殊表达式才用方案五。3. 完整实操从 Controller 到 Mapper 的一次干净查询3.1 表结构与初始数据准备先建一个最小可复现的表结构CREATE TABLE t_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_create_time (create_time) );插入几条测试数据重点覆盖边界值比如 1 号零点、1 号 23:59:59、2 号零点。这是调试时间查询最锋利的测试手段没有边界数据你的临界值对不对根本验证不出来。3.2 Controller 接收字符串Service 完成解析与组装实体类注意在 createTime 字段上加上 MyBatis-Plus 的自动填充配置或者确认数据库默认值能正确映射到实体。Controller 层保持简单直接接收两个字符串GetMapping(/list) public ResultListOrderVO list(RequestParam String startTime, RequestParam String endTime) { return orderService.queryByCreateTime(startTime, endTime); }Service 里的核心逻辑就是解析字符串、组装 Wrapper。我一般这么写public ListOrderEntity queryByCreateTime(String startTime, String endTime) { DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); // 参数兜底如果没传开始时间给一个很早期的默认值 LocalDateTime start (startTime null || startTime.isEmpty()) ? LocalDateTime.of(1970, 1, 1, 0, 0, 0) : LocalDateTime.parse(startTime, formatter); LocalDateTime end (endTime null || endTime.isEmpty()) ? LocalDateTime.now() : LocalDateTime.parse(endTime, formatter); return orderMapper.selectList(Wrappers.OrderEntitylambdaQuery() .ge(OrderEntity::getCreateTime, start) .lt(OrderEntity::getCreateTime, end.plusDays(1))); }这里有一个关键细节对于结束时间我在解析之后直接 plusDays(1)。这样前端传 2024-01-31查询范围就成了 [2024-01-31 00:00:00, 2024-02-01 00:00:00)覆盖了 1 月 31 日全天。这种处理方式比要求前端必须传 2024-01-31 23:59:59 来说更稳妥因为在接口协议里说明结束日期包含当天是一种非常常见的约定。你可以在接口文档里写清楚endTime 传的是结束日期后端会自动按当天最后时刻处理。3.3 临界值计算为什么结束时间要使用次日零点这是整个查询里最容易出错的地方。数据库的 datetime 精度在不同版本、不同配置下不一样老版本的 MySQL 可能只精确到秒新版本5.6.4支持亚秒级精度。如果你的表里恰好存了一条 create_time 为 2024-01-31 23:59:59.888 的数据而你用 le 2024-01-31 23:59:59 去查这条数据就被漏掉了。左闭右开区间也就是 ge 开始时间 lt 次日零点完全规避了这个问题。不只是 MyBatis-PlusJDBC 原生查询、MyBatis XML 里写 SQL我都推荐用这个思路。具体计算其实非常简单LocalDateTime start LocalDateTime.parse(2024-01-15 00:00:00, formatter); LocalDateTime endExclusive start.plusDays(1); // 2024-01-16 00:00:00如果要做最近 7 天的查询开始时间就是今天零点减 6 天结束时间是明天零点。很多人在这一步直接用 now() 加加减减结果把今天的数据也算进去了或者少算了需要特别细心。3.4 封装一个通用时间范围查询工具在实际项目中时间范围查询几乎每个业务模块都会用到。我建议把解析和区间计算逻辑抽成一个工具类避免每个 Service 里都重复写一遍。public class TimeRange { private final LocalDateTime start; private final LocalDateTime endExclusive; private TimeRange(LocalDateTime start, LocalDateTime endExclusive) { this.start start; this.endExclusive endExclusive; } public static TimeRange ofDate(String dateStr) { DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd); LocalDate date LocalDate.parse(dateStr, formatter); return new TimeRange(date.atStartOfDay(), date.plusDays(1).atStartOfDay()); } public static TimeRange ofRange(String startDate, String endDate) { DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd); LocalDate start LocalDate.parse(startDate, formatter); LocalDate end LocalDate.parse(endDate, formatter); return new TimeRange(start.atStartOfDay(), end.plusDays(1).atStartOfDay()); } }用的时候代码立刻变得清爽TimeRange range TimeRange.ofRange(2024-01-01, 2024-01-31); orderMapper.selectList(Wrappers.OrderEntitylambdaQuery() .ge(OrderEntity::getCreateTime, range.getStart()) .lt(OrderEntity::getCreateTime, range.getEndExclusive()));这个工具类看起来简单但在真正做报表需求、导出任务时能省下很多时间。团队里如果有人写 le 23:59:59、有人写 lt 次日 00:00:00时间久了必然出现边界不一致的问题统一封装能把这个差异从源头消灭掉。4. 避坑手册时区、格式、索引、边界的排查实录4.1 时区偏差导致差 8 小时有次排查一个线上问题后台查当天订单数页面凌晨显示的是 0到了上午数据才慢慢对。最后发现是数据库连接串里 serverTimezone 配置和 JVM 默认时区不一致字符串 2024-01-01 00:00:00 被解析成 UTC 时间再转成 Asia/Shanghai 时间就成了 08:00:00。两者相差 8 小时凌晨新增的订单自然查不出来。检查时区主要看两个地方一是 JDBC 连接串里的 serverTimezone二是 MySQL 全局的 time_zone 变量。推荐的配置是统一使用 Asia/Shanghai并且尽量让 JVM、数据库、应用服务器都在同一时区否则你排查问题时会把时间绕晕。4.2 字符串格式不一致导致漏数据另一个常见坑是传入的字符串格式五花八门。有人传 2024-01-01有人传 2024-1-1还有人传 2024/01/01。如果用 DateTimeFormatter.ofPattern(yyyy-MM-dd) 去解析 2024/01/01会直接抛 DateTimeParseException接口 500。这个问题不算难解决但需要你在接口层统一约束格式或者写一个宽松的解析方法把几种常见分隔符都兼容掉。我只提醒一点格式解析失败时不要吞异常然后返回空结果。那样客户端看到的不是参数错误而是没有数据排查问题时会多绕好几个圈。4.3 在索引列上套函数导致的慢查询这个坑在上面已经提过但值得单独拎出来说。很多人习惯用 DATE_FORMAT(create_time, %Y-%m-%d) 2024-01-15 来查询某天数据这种写法确实直观但 MySQL 无法对 create_time 的索引做范围扫描因为索引里存的是原始值不是格式化后的字符串。它只能把每一条记录都格式化一遍再比对等于全表扫描。正确做法是转换成范围条件ge 当天零点、lt 次日零点。这样优化器可以直接走 idx_create_time 索引查询速度完全不在一个量级。4.4 边界条件用错导致统计总差一天我见过最多的问题其实是边界条件的错误选择。统计一周数据时用了 le 2024-01-07 而不是 lt 2024-01-08导致 1 月 7 日下午之后的数据全部缺失。也有相反情况本想查 1 月 1 日到 1 月 7 日的七天数据结果因为用了 lt 2024-01-07只统计了 6 天。这个问题的本质是对数据库时间精度的理解不到位。建议所有时间范围查询都统一为左闭右开且右边界使用次日的零点。配合边界测试数据基本可以杜绝这类问题。4.5 空值处理与潜在 SQL 注入参数为空时很多人的第一反应是直接跳过条件也就是不拼接这个查询条件。但如果你没有判断空值就执行了查询会导致查询范围等于全表轻则接口超时重则把大量数据一次性加载进内存直接把应用打挂。另一个必须警惕的是 apply 方法里的字符串拼接。MyBatis-Plus 的 apply 支持占位符写法应当优先使用 {0} 形式// 正确 wrapper.apply(create_time STR_TO_DATE({0}, %Y-%m-%d), 2024-01-15); // 错误存在 SQL 注入风险 wrapper.apply(create_time STR_TO_DATE( userInput , %Y-%m-%d));我还在代码评审里见过直接把用户输入的字符串拼到 last(ORDER BY ...) 里的情况这几乎等于把数据库钥匙交给攻击者。凡是支持自定义 SQL 片段的地方都走占位符这条原则对任何 ORM 都适用。5. 延展实践从一条查询到一套统计报表的额外注意点5.1 按天分组统计时的时间字段处理时间范围查询常常不是终点后面还要接 GROUP BY 做趋势图。比如统计每天订单量SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, COUNT(*) FROM t_order WHERE create_time #{start} AND create_time #{end} GROUP BY DATE_FORMAT(create_time, %Y-%m-%d)这里同样面临索引失效问题但因为分组查询本来就要扫描大量数据索引的影响会被弱化。更值得关注的是时间字段的时区转换。如果你的应用和数据库不在同一时区分组统计出来的每天边界是数据库时区的零点不是业务时区的零点。我之前就踩过这个坑数据库用的 UTC统计出来的每天订单量整体往后移了 8 小时。5.2 大范围查询时的分页与返回量控制时间范围查询经常会被用在导出功能里用户可能选一个几年的跨度。此时如果直接把查询结果全部加载进内存再写进 Excel容易造成内存溢出。我常用的策略是分页查询或者游标查询。MyBatis-Plus 里可以结合 Page 插件PageOrderEntity page new Page(1, 1000); IPageOrderEntity result orderMapper.selectPage(page, wrapper);之后循环读取直到没有下一页为止同时控制每批的规模。这个思路在数据量几十万、上百万时特别重要。5.3 前端时间组件默认值与后端兜底校验前端用户经常不选时间直接点查询。如果后端没有兜底任由 SQL 不加条件执行后果就是全表扫描。我建议两端协同处理前端给时间选择器设一个合理的默认范围比如最近 7 天后端接口里对空参数做显式判断宁可抛参数校验异常也不要让它变成无范围查询。还有一点需要注意接口返回给前端的提示信息要足够精确。如果用户传了非法的时间格式应当提示时间格式不正确请使用 yyyy-MM-dd而不是说系统异常。这类小细节很影响联调效率。在这些实践之外我再分享一个非常小但是很顺手的技巧写单元测试时把 00:00:00、23:59:59、次日 00:00:00、周末跨月、跨年这几个边界时间点都放进测试用例里。时间查询的 bug 几乎都长在边界附近把这几个点覆盖住了线上出问题的概率能下降一大半。我自己这几年做 Java 后端凡是时间范围相关的需求都是靠这套边界用例稳住的质量。以后你再遇到字符串时间格式查询先想清楚数据库字段类型、时区、边界、索引这四个维度再去写 Wrapper基本就不会翻车了。 MyBatis-Plus字符串时间格式查询的坑与五种写法实战
最近在做运营后台的统计需求时前端抛过来两个字符串时间参数startTime2024-01-01、endTime2024-01-31让我按订单创建时间查一段区间内的数据。项目用的是 MyBatis-Plus我第一反应就是写个 LambdaQueryWrapper把字符串直接塞进 ge 里。页面一刷新数据就是不对。排查到最后发现字符串时间格式查询这件事远比表面看起来复杂。这个坑其实非常典型几乎每个用 MyBatis-Plus 做过时间范围查询的人都会撞上。这篇就把「字符串时间格式查询」从原理到实操摊开讲清楚包含为什么字符串能直接查、什么时候必须转类型、五种常用写法怎么选、某一天查询的临界值边界怎么算以及时区、格式、索引失效这些实战中常见的坑。1. 场景还原为什么会有字符串时间查询这种需求1.1 字符串时间的两个主要来源我见过的大部分时间查询参数都不是 Date 或 LocalDateTime而是字符串。最常见的有两类场景。第一类是前端组件直接传值。Vue 项目里的 el-date-picker、Ant Design 的 DatePicker、laydate 这些组件如果没做值格式化提交给后端的默认值就是 2024-01-15 或者 2024-01-15 10:30:00 这种字符串。后端接口如果用 String 接收那这些字符串就直接进了 Mapper。第二类是历史遗留表字段本身就是 VARCHAR 类型。比如几年前设计的流水表create_time 字段是 varchar(32)存的就是 2024-01-15 10:30:00。这种情况下数据库里根本没有日期类型不管你用什么 ORM最终执行的 SQL 都是字符串匹配。这两类场景看起来都要做字符串时间查询但背后的处理逻辑完全不一样。前者是字符串和日期类型做比较需要依赖数据库的隐式转换后者是字符串和字符串做比较纯粹是字典序匹配。很多人没分清这两者导致 SQL 写出去不是查不到就是结果多出几条。1.2 数据库层的隐式转换到底做了什么先看 MySQL 的处理逻辑。当你有一个 datetime 类型的字段 create_time执行 WHERE create_time 2024-01-01 时MySQL 并不会直接比较字符串和日期而是把 2024-01-01 转成一个合法的日期时间值再和 create_time 对比。这个转换规则在意料之中但也最容易出问题。比如字符串是 2024-01-01MySQL 会把它解析成 2024-01-01 00:00:00。此时用 去查可以查出 1 号零点之后的所有数据。但如果字符串是 2024-01-01 10:00:00而你拿它去和 date 类型字段比较date 字段会先转成 datetime即 2024-01-01 00:00:00再和字符串值比较两者就不相等。用 查询时当天 10 点之后的数据永远匹配不上。这里有个生活化的类比你把一个写好了收件门牌号的快递单交给快递员快递员的系统里也有一份门牌号记录。只要两边门牌号格式一致就能正常投递格式一旦不一致哪怕指向同一个位置系统也认不出来。所以在 MyBatis-Plus 里写查询前先搞清楚你的字符串会被数据库如何解析是第一步。这决定了你要用 、、、BETWEEN 还是 DATE_FORMAT 函数。2. 五种写法对比从直接比较到封装工具类2.1 粗暴型字符串直接塞进 Wrapper最直接的方式是这样的LambdaQueryWrapperOrderEntity wrapper Wrappers.lambdaQuery(); wrapper.ge(OrderEntity::getCreateTime, 2024-01-01) .le(OrderEntity::getCreateTime, 2024-01-31); ListOrderEntity list orderMapper.selectList(wrapper);这种方式能不能跑通能。前提是数据库的 create_time 字段是 datetime而你传入的字符串刚好是 MySQL 能识别的标准格式。MySQL 会把这两个字符串转成 datetime执行结果基本符合预期。但隐患也很明显。第一字符串格式一旦变成 2024/01/01 或 20240101隐式转换规则就会变得不可控可能直接报错也可能查不出数据。第二如果 create_time 字段恰好是 VARCHAR那这条 SQL 就变成了字符串字典序比较2024-01-31 和 2024-2-1 这种值会排在完全不同的位置查询结果极其容易漏数据。我的建议是写 Demo 可以这么玩生产代码里尽量别直接用。2.2 推荐型Service 层转成 LocalDateTime这个方案是我最常用的也是我认为最稳的接口接收 String在 Service 层用 DateTimeFormatter 解析成 LocalDateTime再传给 Wrapper。DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); LocalDateTime start LocalDateTime.parse(2024-01-01 00:00:00, formatter); LocalDateTime end LocalDateTime.parse(2024-01-31 23:59:59, formatter); LambdaQueryWrapperOrderEntity wrapper Wrappers.lambdaQuery(); wrapper.ge(OrderEntity::getCreateTime, start) .le(OrderEntity::getCreateTime, end);这样做的优势在于Java 层已经帮你完成了字符串合法性的校验格式不对会在 parse 阶段直接抛异常而不是等到 SQL 执行时才暴露。同时传给数据库的是真正的日期时间对象MyBatis-Plus 会使用类型处理器把 LocalDateTime 转成 JDBC 需要的 Timestamp不依赖 MySQL 的隐式转换语义清晰。如果你用的是 JDK 8 之前的项目也可以用 SimpleDateFormat 转成 java.util.Date效果一样。2.3 取巧型数据库函数配合字符串还有一部分人会这么写wrapper.apply(DATE_FORMAT(create_time, %Y-%m-%d) {0}, 2024-01-15);这个写法能精确匹配某一天字符串格式也非常灵活只要和格式化模板一致即可。但我强烈不建议在查询条件里这么干核心原因是索引会失效。create_time 字段上如果建了索引一旦在 WHERE 条件里用 DATE_FORMAT 将它包起来MySQL 就无法使用该索引只能全表扫描。数据量小没事数据量到了千万级这条 SQL 直接拖垮数据库。2.4 区间型Between 解决某一天查询查询某一天的数据很多人都想用 betweenwrapper.between(OrderEntity::getCreateTime, 2024-01-15 00:00:00, 2024-01-15 23:59:59);这个写法逻辑上没错边界也理解对了。但它有个隐蔽的坑如果字符串格式里带了毫秒或 23:59:59.999而数据库存储的时间包含微秒边界值就可能会丢数据。更稳妥的写法是左闭右开区间wrapper.ge(OrderEntity::getCreateTime, 2024-01-15 00:00:00) .lt(OrderEntity::getCreateTime, 2024-01-16 00:00:00);用 lt 包住第二天零点比用 le 传当天 23:59:59更安全。因为那一天最后一秒可能是 23:59:59.5也可能有微秒值直接 le 23:59:59 会把 23:59:59.500 这种数据挡在门外。2.5 兜底型apply 自定义条件片段如果查询逻辑实在复杂比如要传一个函数表达式、要按周查询、要按季度查询LambdaQueryWrapper 自带的条件可能不够用。这时可以用 apply 写自定义 SQL 片段wrapper.apply(create_time STR_TO_DATE({0}, %Y-%m-%d), 2024-01-15);注意 apply 里的 {0} 是占位符MyBatis-Plus 会把它替换成参数占位符 ?而不是直接拼接字符串。这能有效防止 SQL 注入。千万不要自己用字符串拼接把用户输入直接写进条件里那是安全大忌。我把这五种方案的取舍整理成了一张表方案适用场景优点必须注意的坑直接塞字符串临时排查数据代码最少写法直观依赖隐式转换格式稍有不符就出问题Service 转 LocalDateTime日常业务查询类型安全格式校验在前可读性强需要多写几行解析代码DATE_FORMAT 函数不需要走索引的小表查询格式匹配灵活索引失效数据量大时慢查询Between / gelt 区间查询某一天或固定范围边界清晰索引友好边界值要仔细计算apply 自定义片段复杂表达式或函数查询灵活可控性强必须用占位符防注入实际选择时我的原则很简单常规查询优先方案二固定某一天优先方案四特殊表达式才用方案五。3. 完整实操从 Controller 到 Mapper 的一次干净查询3.1 表结构与初始数据准备先建一个最小可复现的表结构CREATE TABLE t_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_create_time (create_time) );插入几条测试数据重点覆盖边界值比如 1 号零点、1 号 23:59:59、2 号零点。这是调试时间查询最锋利的测试手段没有边界数据你的临界值对不对根本验证不出来。3.2 Controller 接收字符串Service 完成解析与组装实体类注意在 createTime 字段上加上 MyBatis-Plus 的自动填充配置或者确认数据库默认值能正确映射到实体。Controller 层保持简单直接接收两个字符串GetMapping(/list) public ResultListOrderVO list(RequestParam String startTime, RequestParam String endTime) { return orderService.queryByCreateTime(startTime, endTime); }Service 里的核心逻辑就是解析字符串、组装 Wrapper。我一般这么写public ListOrderEntity queryByCreateTime(String startTime, String endTime) { DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss); // 参数兜底如果没传开始时间给一个很早期的默认值 LocalDateTime start (startTime null || startTime.isEmpty()) ? LocalDateTime.of(1970, 1, 1, 0, 0, 0) : LocalDateTime.parse(startTime, formatter); LocalDateTime end (endTime null || endTime.isEmpty()) ? LocalDateTime.now() : LocalDateTime.parse(endTime, formatter); return orderMapper.selectList(Wrappers.OrderEntitylambdaQuery() .ge(OrderEntity::getCreateTime, start) .lt(OrderEntity::getCreateTime, end.plusDays(1))); }这里有一个关键细节对于结束时间我在解析之后直接 plusDays(1)。这样前端传 2024-01-31查询范围就成了 [2024-01-31 00:00:00, 2024-02-01 00:00:00)覆盖了 1 月 31 日全天。这种处理方式比要求前端必须传 2024-01-31 23:59:59 来说更稳妥因为在接口协议里说明结束日期包含当天是一种非常常见的约定。你可以在接口文档里写清楚endTime 传的是结束日期后端会自动按当天最后时刻处理。3.3 临界值计算为什么结束时间要使用次日零点这是整个查询里最容易出错的地方。数据库的 datetime 精度在不同版本、不同配置下不一样老版本的 MySQL 可能只精确到秒新版本5.6.4支持亚秒级精度。如果你的表里恰好存了一条 create_time 为 2024-01-31 23:59:59.888 的数据而你用 le 2024-01-31 23:59:59 去查这条数据就被漏掉了。左闭右开区间也就是 ge 开始时间 lt 次日零点完全规避了这个问题。不只是 MyBatis-PlusJDBC 原生查询、MyBatis XML 里写 SQL我都推荐用这个思路。具体计算其实非常简单LocalDateTime start LocalDateTime.parse(2024-01-15 00:00:00, formatter); LocalDateTime endExclusive start.plusDays(1); // 2024-01-16 00:00:00如果要做最近 7 天的查询开始时间就是今天零点减 6 天结束时间是明天零点。很多人在这一步直接用 now() 加加减减结果把今天的数据也算进去了或者少算了需要特别细心。3.4 封装一个通用时间范围查询工具在实际项目中时间范围查询几乎每个业务模块都会用到。我建议把解析和区间计算逻辑抽成一个工具类避免每个 Service 里都重复写一遍。public class TimeRange { private final LocalDateTime start; private final LocalDateTime endExclusive; private TimeRange(LocalDateTime start, LocalDateTime endExclusive) { this.start start; this.endExclusive endExclusive; } public static TimeRange ofDate(String dateStr) { DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd); LocalDate date LocalDate.parse(dateStr, formatter); return new TimeRange(date.atStartOfDay(), date.plusDays(1).atStartOfDay()); } public static TimeRange ofRange(String startDate, String endDate) { DateTimeFormatter formatter DateTimeFormatter.ofPattern(yyyy-MM-dd); LocalDate start LocalDate.parse(startDate, formatter); LocalDate end LocalDate.parse(endDate, formatter); return new TimeRange(start.atStartOfDay(), end.plusDays(1).atStartOfDay()); } }用的时候代码立刻变得清爽TimeRange range TimeRange.ofRange(2024-01-01, 2024-01-31); orderMapper.selectList(Wrappers.OrderEntitylambdaQuery() .ge(OrderEntity::getCreateTime, range.getStart()) .lt(OrderEntity::getCreateTime, range.getEndExclusive()));这个工具类看起来简单但在真正做报表需求、导出任务时能省下很多时间。团队里如果有人写 le 23:59:59、有人写 lt 次日 00:00:00时间久了必然出现边界不一致的问题统一封装能把这个差异从源头消灭掉。4. 避坑手册时区、格式、索引、边界的排查实录4.1 时区偏差导致差 8 小时有次排查一个线上问题后台查当天订单数页面凌晨显示的是 0到了上午数据才慢慢对。最后发现是数据库连接串里 serverTimezone 配置和 JVM 默认时区不一致字符串 2024-01-01 00:00:00 被解析成 UTC 时间再转成 Asia/Shanghai 时间就成了 08:00:00。两者相差 8 小时凌晨新增的订单自然查不出来。检查时区主要看两个地方一是 JDBC 连接串里的 serverTimezone二是 MySQL 全局的 time_zone 变量。推荐的配置是统一使用 Asia/Shanghai并且尽量让 JVM、数据库、应用服务器都在同一时区否则你排查问题时会把时间绕晕。4.2 字符串格式不一致导致漏数据另一个常见坑是传入的字符串格式五花八门。有人传 2024-01-01有人传 2024-1-1还有人传 2024/01/01。如果用 DateTimeFormatter.ofPattern(yyyy-MM-dd) 去解析 2024/01/01会直接抛 DateTimeParseException接口 500。这个问题不算难解决但需要你在接口层统一约束格式或者写一个宽松的解析方法把几种常见分隔符都兼容掉。我只提醒一点格式解析失败时不要吞异常然后返回空结果。那样客户端看到的不是参数错误而是没有数据排查问题时会多绕好几个圈。4.3 在索引列上套函数导致的慢查询这个坑在上面已经提过但值得单独拎出来说。很多人习惯用 DATE_FORMAT(create_time, %Y-%m-%d) 2024-01-15 来查询某天数据这种写法确实直观但 MySQL 无法对 create_time 的索引做范围扫描因为索引里存的是原始值不是格式化后的字符串。它只能把每一条记录都格式化一遍再比对等于全表扫描。正确做法是转换成范围条件ge 当天零点、lt 次日零点。这样优化器可以直接走 idx_create_time 索引查询速度完全不在一个量级。4.4 边界条件用错导致统计总差一天我见过最多的问题其实是边界条件的错误选择。统计一周数据时用了 le 2024-01-07 而不是 lt 2024-01-08导致 1 月 7 日下午之后的数据全部缺失。也有相反情况本想查 1 月 1 日到 1 月 7 日的七天数据结果因为用了 lt 2024-01-07只统计了 6 天。这个问题的本质是对数据库时间精度的理解不到位。建议所有时间范围查询都统一为左闭右开且右边界使用次日的零点。配合边界测试数据基本可以杜绝这类问题。4.5 空值处理与潜在 SQL 注入参数为空时很多人的第一反应是直接跳过条件也就是不拼接这个查询条件。但如果你没有判断空值就执行了查询会导致查询范围等于全表轻则接口超时重则把大量数据一次性加载进内存直接把应用打挂。另一个必须警惕的是 apply 方法里的字符串拼接。MyBatis-Plus 的 apply 支持占位符写法应当优先使用 {0} 形式// 正确 wrapper.apply(create_time STR_TO_DATE({0}, %Y-%m-%d), 2024-01-15); // 错误存在 SQL 注入风险 wrapper.apply(create_time STR_TO_DATE( userInput , %Y-%m-%d));我还在代码评审里见过直接把用户输入的字符串拼到 last(ORDER BY ...) 里的情况这几乎等于把数据库钥匙交给攻击者。凡是支持自定义 SQL 片段的地方都走占位符这条原则对任何 ORM 都适用。5. 延展实践从一条查询到一套统计报表的额外注意点5.1 按天分组统计时的时间字段处理时间范围查询常常不是终点后面还要接 GROUP BY 做趋势图。比如统计每天订单量SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, COUNT(*) FROM t_order WHERE create_time #{start} AND create_time #{end} GROUP BY DATE_FORMAT(create_time, %Y-%m-%d)这里同样面临索引失效问题但因为分组查询本来就要扫描大量数据索引的影响会被弱化。更值得关注的是时间字段的时区转换。如果你的应用和数据库不在同一时区分组统计出来的每天边界是数据库时区的零点不是业务时区的零点。我之前就踩过这个坑数据库用的 UTC统计出来的每天订单量整体往后移了 8 小时。5.2 大范围查询时的分页与返回量控制时间范围查询经常会被用在导出功能里用户可能选一个几年的跨度。此时如果直接把查询结果全部加载进内存再写进 Excel容易造成内存溢出。我常用的策略是分页查询或者游标查询。MyBatis-Plus 里可以结合 Page 插件PageOrderEntity page new Page(1, 1000); IPageOrderEntity result orderMapper.selectPage(page, wrapper);之后循环读取直到没有下一页为止同时控制每批的规模。这个思路在数据量几十万、上百万时特别重要。5.3 前端时间组件默认值与后端兜底校验前端用户经常不选时间直接点查询。如果后端没有兜底任由 SQL 不加条件执行后果就是全表扫描。我建议两端协同处理前端给时间选择器设一个合理的默认范围比如最近 7 天后端接口里对空参数做显式判断宁可抛参数校验异常也不要让它变成无范围查询。还有一点需要注意接口返回给前端的提示信息要足够精确。如果用户传了非法的时间格式应当提示时间格式不正确请使用 yyyy-MM-dd而不是说系统异常。这类小细节很影响联调效率。在这些实践之外我再分享一个非常小但是很顺手的技巧写单元测试时把 00:00:00、23:59:59、次日 00:00:00、周末跨月、跨年这几个边界时间点都放进测试用例里。时间查询的 bug 几乎都长在边界附近把这几个点覆盖住了线上出问题的概率能下降一大半。我自己这几年做 Java 后端凡是时间范围相关的需求都是靠这套边界用例稳住的质量。以后你再遇到字符串时间格式查询先想清楚数据库字段类型、时区、边界、索引这四个维度再去写 Wrapper基本就不会翻车了。