MyBatisPlus查询方法避坑指南：从生产事故看selectOne的正确使用姿势
上周团队里刚发生一起线上事故——用户积分无故清零。排查后发现是某位同事在代码中误用了selectOne方法，导致本该返回唯一结果的查询匹配到多条数据，系统错误地取了第一条记录的积分值进行更新。这种问题在MyBatisPlus的使用中并不罕见，今天我就结合三个真实踩坑案例，聊聊那些容易被误用的查询方法。
1. selectOne的三大致命陷阱与解决方案
1.1 你以为返回的是唯一结果？其实它在悄悄截断数据
去年双十一大促时，我们商品服务的库存扣减接口出现异常。日志显示同一个SKU在短时间内被多个订单重复扣减，进一步排查发现是这段代码惹的祸：
QueryWrapper<Product> wrapper = new QueryWrapper<>(); wrapper.eq("sku_code", "SKU123456"); Product product = productMapper.selectOne(wrapper);问题本质：当数据库中存在多条sku_code相同的记录时，selectOne不会抛出异常，而是静默返回第一条数据。这导致后续库存操作基于错误的数据进行。
正确姿势：
// 方案1：确保字段有唯一索引 QueryWrapper<Product> wrapper = new QueryWrapper<>(); wrapper.eq("sku_code", "SKU123456"); Long count = productMapper.selectCount(wrapper); if(count > 1) { throw new BusinessException("存在重复SKU记录"); } Product product = productMapper.selectOne(wrapper); // 方案2：使用limit 1明确限制 QueryWrapper<Product> wrapper = new QueryWrapper<>(); wrapper.eq("sku_code", "SKU123456").last("LIMIT 1"); Product product = productMapper.selectOne(wrapper);1.2 空指针陷阱：当查询无结果时
新手常犯的错误是直接使用返回对象进行操作：
User user = userMapper.selectOne(wrapper); String username = user.getUsername(); // 可能NPE防御性写法：
Optional.ofNullable(userMapper.selectOne(wrapper)) .ifPresent(user -> { // 安全操作 });1.3 性能黑洞：在大表上的全表扫描
即使你确信条件能命中唯一记录，没有合适索引的selectOne也可能成为性能杀手。某次我们API响应突然变慢，最终定位到：
QueryWrapper<Log> wrapper = new QueryWrapper<>(); wrapper.eq("trace_id", traceId); Log log = logMapper.selectOne(wrapper); // trace_id字段无索引优化方案：
| 优化手段 | 实施方法 | 效果对比 |
|---|---|---|
| 添加索引 | ALTER TABLE log ADD INDEX idx_trace_id(trace_id) | 查询从200ms降至2ms |
| 使用selectById | 设计时考虑用自增ID替代 | 避免全表扫描 |
| 缓存层 | 高频查询结果放入Redis | 减少DB压力 |
2. selectByMap的隐藏成本与替代方案
2.1 为什么说它是性能杀手
在用户中心服务中，我们曾用以下代码查询用户：
Map<String, Object> map = new HashMap<>(); map.put("age", 18); map.put("city", "北京"); List<User> users = userMapper.selectByMap(map);问题诊断：
- 无法使用复合索引（MySQL只能利用最左前缀）
- 参数类型不安全（Map的value是Object）
- 条件逻辑固定（只能AND连接）
2.2 LambdaQueryWrapper的降维打击
改用Lambda表达式后，代码更安全且性能提升：
List<User> users = userMapper.selectList( new LambdaQueryWrapper<User>() .eq(User::getAge, 18) .eq(User::getCity, "北京") );优势对比：
| 特性 | selectByMap | LambdaQueryWrapper |
|---|---|---|
| 类型安全 | ❌ | ✅ |
| 索引利用 | 有限 | 优化 |
| 条件组合 | 仅AND | 支持复杂逻辑 |
| 可读性 | 差 | 优秀 |
3. 分页查询的那些"坑爹"行为
3.1 你以为的PageHelper并不是你以为的
常见错误用法：
PageHelper.startPage(1, 10); List<User> users = userMapper.selectList(wrapper); // 失效！正确打开方式：
// 方式1：MyBatisPlus原生分页 Page<User> page = new Page<>(1, 10); userMapper.selectPage(page, wrapper); // 方式2：自定义分页SQL @Select("SELECT * FROM user ${ew.customSqlSegment}") Page<User> selectCustomPage(Page<User> page, @Param(Constants.WRAPPER) Wrapper<User> wrapper);3.2 千万级数据分页的优化技巧
当处理大数据量时，传统LIMIT offset, size方式会导致性能急剧下降。我们通过以下方案优化：
-- 低效写法 SELECT * FROM orders LIMIT 1000000, 20; -- 优化方案（基于游标） SELECT * FROM orders WHERE id > 1000000 ORDER BY id LIMIT 20;对应Java实现：
Page<Order> page = new Page<>(1, 20); page.setSearchCount(false); // 禁用count查询 wrapper.gt(Order::getId, lastMaxId) .orderByAsc(Order::getId); orderMapper.selectPage(page, wrapper);4. 项目实战：构建安全的查询体系
4.1 查询方法选择决策树
是否需要精确匹配唯一记录？ ├─ 是 → 确保条件能命中唯一索引 → selectOne ├─ 否 → 需要分页？ ├─ 是 → selectPage ├─ 否 → 按ID批量查询？ ├─ 是 → selectBatchIds ├─ 否 → selectList + LambdaWrapper4.2 我们团队制定的查询规范
- 强制：所有
selectOne调用必须前置selectCount校验 - 推荐：禁用
selectByMap，统一使用LambdaWrapper - 约定：分页查询必须明确是否执行count查询
- 审查：所有查询条件字段必须建立合适索引
// 合规查询示例 public User getByUsername(String username) { Long count = userMapper.selectCount( new LambdaQueryWrapper<User>() .eq(User::getUsername, username) ); if(count != 1) { throw new IllegalStateException("用户名不唯一"); } return userMapper.selectOne( new LambdaQueryWrapper<User>() .eq(User::getUsername, username) ); }在电商核心交易系统中，我们通过这套规范将查询相关故障率降低了82%。记住：MyBatisPlus的便捷不是放纵的理由，越是简单的API，越需要谨慎对待。
)
