从JDBC到MyBatis：Java数据库访问的演进与实践-代码聚汇网

从JDBC到MyBatis：Java数据库访问的演进与实践

Forest Hu·2026-08-27·阅读 23 GEO检测（免费）

JDBCMyBatisORM

|难度：普通|阅读约 23 分钟

1. 为什么我们需要从JDBC走向MyBatis

十年前我刚入行做Java开发时，项目里清一色都是纯JDBC操作数据库。那时候最怕的就是写SQL拼接——一个简单的条件查询就要写十几行StringBuffer.append()，还要小心翼翼地处理各种单引号和逗号。更可怕的是，每次发布新版本前，团队总要花两天时间专门修复SQL注入漏洞。

JDBC（Java Database Connectivity）作为Java官方的数据库连接规范，确实为数据库操作提供了基础能力。但原生JDBC的这些问题也实实在在困扰着开发者：

需要手动管理数据库连接（开/关连接池）
SQL与Java代码强耦合（修改SQL需要重新编译）
结果集处理繁琐（需要遍历ResultSet手动映射）
缺乏类型安全（全靠字符串拼接）

直到2010年MyBatis出现，这些问题才得到系统性解决。我清楚地记得第一次用MyBatis时的震撼——原来数据库操作可以这么优雅！一个XML配置就能把SQL和Java对象自动映射，参数化查询天然防注入，动态SQL支持各种复杂条件组合。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. JDBC核心痛点与演进路线

2.1 原生JDBC的四大短板

让我们通过一个典型场景来对比两种方式。假设要实现用户分页查询功能，以下是原生JDBC的实现：

java复制// JDBC分页查询示例
public List<User> findUsers(int pageNo, int pageSize) throws SQLException {
    String sql = "SELECT * FROM users LIMIT " + (pageNo-1)*pageSize + "," + pageSize;
    Connection conn = null;
    PreparedStatement stmt = null;
    ResultSet rs = null;
    List<User> users = new ArrayList<>();
    
    try {
        conn = dataSource.getConnection();
        stmt = conn.prepareStatement(sql);
        rs = stmt.executeQuery();
        while(rs.next()) {
            User user = new User();
            user.setId(rs.getLong("id"));
            user.setName(rs.getString("name"));
            // 其他字段...
            users.add(user);
        }
    } finally {
        if(rs != null) rs.close();
        if(stmt != null) stmt.close();
        if(conn != null) conn.close();
    }
    return users;
}

这段代码暴露了JDBC的典型问题：

资源管理复杂：需要手动处理Connection/Statement/ResultSet的开启关闭
SQL注入风险：直接拼接分页参数存在安全漏洞
对象映射繁琐：需要逐字段从ResultSet提取并set到对象
SQL硬编码：修改SQL必须重新编译Java代码

2.2 ORM框架的演进历程

行业先后出现了几种解决方案：

Hibernate：全自动ORM，完全屏蔽SQL，但复杂查询性能较差
JPA：标准化ORM接口，但灵活性不足
MyBatis：半自动ORM，保留SQL控制权的同时简化开发

MyBatis之所以能成为主流，是因为它在SQL可控性和开发效率之间取得了完美平衡。根据2022年Java生态调查报告，MyBatis在国内Java项目中的使用率高达78%，远超Hibernate的35%。

3. MyBatis核心机制解析

3.1 架构设计的三层抽象

MyBatis通过三个核心组件解耦数据库操作：

SqlSessionFactory：全局单例，负责创建SqlSession
SqlSession：一次数据库会话的抽象，线程不安全
Mapper接口：声明数据库操作方法

这种设计带来了几个关键优势：

连接池管理自动化（集成HikariCP等）
SQL与Java代码分离（XML/注解两种方式）
方法调用转化为动态代理

3.2 动态SQL的魔法

MyBatis最强大的特性之一是动态SQL。对比前面的分页例子，MyBatis的实现：

xml复制<!-- UserMapper.xml -->
<select id="findUsers" resultType="User">
    SELECT * FROM users
    <where>
        <if test="name != null">
            AND name LIKE #{name}
        </if>
        <if test="status != null">
            AND status = #{status}
        </if>
    </where>
    LIMIT #{offset}, #{pageSize}
</select>

java复制// Mapper接口
public interface UserMapper {
    List<User> findUsers(
        @Param("name") String name,
        @Param("status") Integer status,
        @Param("offset") int offset,
        @Param("pageSize") int pageSize);
}

这种写法解决了JDBC时代的几个痛点：

参数自动预编译（防注入）
条件动态组合（无需拼接字符串）
结果自动映射（无需手动set字段）
SQL可视化维护（独立XML文件）

3.3 类型处理器的秘密

MyBatis内置了上百个TypeHandler（类型处理器），负责Java类型与JDBC类型转换。比如：

StringTypeHandler：处理VARCHAR/CHAR
IntegerTypeHandler：处理INTEGER
DateTypeHandler：处理TIMESTAMP

我们也可以自定义处理器。比如处理枚举类：

java复制public class StatusEnumHandler extends BaseTypeHandler<StatusEnum> {
    @Override
    public void setNonNullParameter(PreparedStatement ps, int i, 
            StatusEnum parameter, JdbcType jdbcType) {
        ps.setInt(i, parameter.getCode());
    }
    
    @Override
    public StatusEnum getNullableResult(ResultSet rs, String columnName) {
        return StatusEnum.of(rs.getInt(columnName));
    }
    // 其他重载方法...
}

然后在配置中注册：

xml复制<typeHandlers>
    <typeHandler handler="com.example.StatusEnumHandler"/>
</typeHandlers>

4. 从JDBC迁移到MyBatis的实战指南

4.1 环境准备与配置

添加Maven依赖：

xml复制<dependency>
    <groupId>org.mybatis</groupId>
    <artifactId>mybatis</artifactId>
    <version>3.5.10</version>
</dependency>
<dependency>
    <groupId>com.zaxxer</groupId>
    <artifactId>HikariCP</artifactId>
    <version>5.0.1</version>
</dependency>

配置mybatis-config.xml：

xml复制<configuration>
    <environments default="development">
        <environment id="development">
            <transactionManager type="JDBC"/>
            <dataSource type="POOLED">
                <property name="driver" value="com.mysql.jdbc.Driver"/>
                <property name="url" value="jdbc:mysql://localhost:3306/test"/>
                <property name="username" value="root"/>
                <property name="password" value="123456"/>
            </dataSource>
        </environment>
    </environments>
    <mappers>
        <mapper resource="mapper/UserMapper.xml"/>
    </mappers>
</configuration>

4.2 渐进式迁移策略

对于存量JDBC项目，建议采用渐进式迁移：

从查询开始：先迁移SELECT语句，保持写操作仍用JDBC
分模块迁移：按业务模块逐个替换，比如先迁移用户模块
双写验证：新旧实现并行运行，比对结果确保一致性

我曾在一个电商项目中用三个月时间完成了从JDBC到MyBatis的迁移，关键经验是：

建立完善的DAO层单元测试
使用AOP记录SQL执行日志对比
逐步替换而不要一次性重写

4.3 性能优化技巧

批量操作：相比JDBC的addBatch()，MyBatis提供了更优雅的批量插入：

java复制// 批量插入用户
try(SqlSession session = sqlSessionFactory.openSession(ExecutorType.BATCH)) {
    UserMapper mapper = session.getMapper(UserMapper.class);
    for(User user : userList) {
        mapper.insert(user);
    }
    session.commit();
}

二级缓存：配置缓存提升查询性能：

xml复制<cache eviction="LRU" flushInterval="60000" size="512" readOnly="true"/>

延迟加载：对于关联查询，使用懒加载避免N+1问题：

xml复制<resultMap id="userWithOrders" type="User">
    <collection property="orders" column="id" 
        select="com.example.mapper.OrderMapper.findByUserId"
        fetchType="lazy"/>
</resultMap>

5. 常见问题与解决方案

5.1 连接池配置陷阱

很多从JDBC转来的开发者会忽略连接池配置，导致生产环境出现问题。以下是一个推荐的HikariCP配置：

properties复制# 连接池大小
spring.datasource.hikari.maximum-pool-size=20
# 连接超时(毫秒)
spring.datasource.hikari.connection-timeout=30000
# 空闲超时(毫秒)
spring.datasource.hikari.idle-timeout=600000
# 最大生命周期(毫秒)
spring.datasource.hikari.max-lifetime=1800000

我曾遇到过一个线上事故：默认连接池大小只有10，在高并发时导致大量请求等待连接。调整到50后问题解决。

5.2 动态SQL的坑

虽然动态SQL强大，但有些边界情况需要注意：

<where>标签的陷阱：当所有条件都为null时，<where>会生成错误的SQL：

sql复制SELECT * FROM user WHERE

解决方案是添加一个永真条件：

xml复制<where>
    <if test="true">1=1</if>
    <!-- 其他条件 -->
</where>

<foreach>的内存问题：大列表IN查询会导致SQL过长：

xml复制<!-- 不好的写法 -->
<select id="findByIds">
    SELECT * FROM user WHERE id IN
    <foreach item="id" collection="ids" open="(" separator="," close=")">
        #{id}
    </foreach>
</select>

建议改为分批查询或使用临时表。

5.3 插件开发实战

MyBatis的插件机制可以拦截四大对象：

Executor (执行器)
StatementHandler (SQL语法构建)
ParameterHandler (参数处理)
ResultSetHandler (结果集处理)

比如实现一个SQL执行时间统计插件：

java复制@Intercepts({
    @Signature(type= Executor.class, method="update", 
        args={MappedStatement.class,Object.class}),
    @Signature(type= Executor.class, method="query",
        args={MappedStatement.class,Object.class,RowBounds.class,ResultHandler.class}) 
})
public class SqlCostPlugin implements Interceptor {
    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        long start = System.currentTimeMillis();
        try {
            return invocation.proceed();
        } finally {
            long cost = System.currentTimeMillis() - start;
            MappedStatement ms = (MappedStatement) invocation.getArgs()[0];
            System.out.println(ms.getId() + " execute cost: " + cost + "ms");
        }
    }
}

在配置中注册：

xml复制<plugins>
    <plugin interceptor="com.example.SqlCostPlugin"/>
</plugins>

6. MyBatis与新一代工具对比

6.1 MyBatis-Plus的增强

MyBatis-Plus在原生MyBatis基础上提供了更多便利：

通用Mapper：内置CRUD方法
Lambda表达式：类型安全的查询条件
自动分页：无需手动计算offset

java复制// MyBatis-Plus示例
Page<User> page = new Page<>(1, 10);
LambdaQueryWrapper<User> wrapper = Wrappers.lambdaQuery();
wrapper.eq(User::getStatus, 1)
       .like(User::getName, "张");
userMapper.selectPage(page, wrapper);

6.2 与JPA的对比选择

项目选型时需要考虑的因素：

维度	MyBatis系列	JPA(Hibernate)
SQL控制度	完全控制	有限控制
开发效率	中等	高
复杂查询	优	良
对象关联	手动配置	自动管理
学习曲线	平缓	陡峭
社区支持	国内活跃	国际主流

我的经验法则是：

需要复杂SQL或高性能查询 → MyBatis
简单CRUD为主 → JPA
国内项目 → MyBatis
国际化项目 → JPA

7. 真实项目中的最佳实践

7.1 多数据源配置

中大型项目通常需要访问多个数据库。配置示例：

java复制@Configuration
@MapperScan(basePackages = "com.example.mapper.db1", 
           sqlSessionFactoryRef = "db1SqlSessionFactory")
public class Db1Config {
    
    @Bean
    @ConfigurationProperties("spring.datasource.db1")
    public DataSource db1DataSource() {
        return DataSourceBuilder.create().build();
    }
    
    @Bean
    public SqlSessionFactory db1SqlSessionFactory(
            @Qualifier("db1DataSource") DataSource dataSource) throws Exception {
        SqlSessionFactoryBean bean = new SqlSessionFactoryBean();
        bean.setDataSource(dataSource);
        bean.setMapperLocations(new PathMatchingResourcePatternResolver()
                .getResources("classpath:mapper/db1/*.xml"));
        return bean.getObject();
    }
}
// 同理配置db2...

7.2 分库分表方案

面对海量数据时，常见的分片策略：

哈希分片：按id哈希值分配到不同表

xml复制<!-- 分表查询示例 -->
<select id="selectById" resultType="User">
    SELECT * FROM user_${tableSuffix} 
    WHERE id = #{id}
</select>

时间分片：按创建时间分表

java复制// 根据时间计算表名
public String getTableName(Date createTime) {
    SimpleDateFormat sdf = new SimpleDateFormat("yyyyMM");
    return "user_" + sdf.format(createTime);
}

7.3 监控与调优

生产环境必备的监控指标：

SQL执行耗时分布
慢SQL统计（超过500ms）
连接池使用情况
缓存命中率

推荐集成Prometheus监控：

java复制public class MyBatisMetricsInterceptor implements Interceptor {
    private final Counter sqlCounter = Counter.build()
            .name("mybatis_sql_total")
            .help("Total MyBatis SQL executions")
            .register();
    
    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        sqlCounter.inc();
        // 其他监控逻辑...
        return invocation.proceed();
    }
}

8. 从MyBatis到更现代的方案

虽然MyBatis解决了JDBC的大部分痛点，但技术总是在演进。近年来出现了一些新思路：

JOOQ：类型安全的SQL构建器
QueryDSL：基于注解的查询DSL
Spring Data JDBC：轻量级ORM方案

但根据我的观察，MyBatis在可预见的未来仍会是Java生态中数据库访问的主流选择，特别是在：

需要复杂SQL优化的场景
遗留系统维护升级
对SQL有严格管控要求的金融领域

迁移到MyBatis不是终点，而是一个新的起点。掌握其原理和最佳实践后，你会发现原来枯燥的数据库操作也可以如此高效优雅。