高效查询的艺术：MyBatis-Plus中LIMIT 1的优雅实践

在Java后端开发中，数据库查询性能优化是个永恒的话题。最近在代码审查时，我发现团队里不少同事习惯性地使用MyBatis-Plus的getOne方法，却很少有人注意到它可能带来的性能隐患。这让我想起去年遇到的一个生产事故——一个看似简单的查询接口在高并发时竟然拖垮了整个数据库，排查后发现正是由于缺少LIMIT 1导致的全表扫描。

1. 为什么你的getOne可能是个性能陷阱

MyBatis-Plus作为MyBatis的增强工具，确实为我们提供了诸多便利。但便利的背后，往往隐藏着一些容易被忽视的细节。让我们先来看看getOne方法的实现本质：

java复制// MyBatis-Plus 3.x的getOne实现
T getOne(Wrapper<T> queryWrapper, boolean throwEx) {
    return throwEx 
        ? this.baseMapper.selectOne(queryWrapper)
        : SqlHelper.getObject(this.log, this.baseMapper.selectList(queryWrapper));
}

这个实现暴露了两个关键问题：

1. 底层调用的是selectList：即使你只需要一条记录，它仍然会查询所有匹配的记录
2. 内存过滤风险：当匹配记录很多时，所有数据都会被加载到JVM内存中

我曾经做过一个简单的压力测试，在一个包含100万条记录的表中：

这个差距在低并发时可能不明显，但在高并发场景下，就会成为系统瓶颈。

2. 常规解决方案的优劣分析

面对这个问题，开发者通常会有以下几种解决方案：

2.1 原生SQL方案

在mapper.xml中直接编写SQL并添加LIMIT 1：

xml复制<select id="selectUserByNam