Spring Boot整合MyBatis时，CURD操作数据库无反应

Question

在Spring Boot整合MyBatis的项目中，常出现CURD操作执行无反应、数据库数据未更新的问题。典型表现为Service层方法正常调用Mapper接口的insert、update等方法，日志显示SQL已输出，但数据库无变化，且无异常抛出。该问题多因事务配置不当导致：如@Service类未添加@Transactional注解，或事务未正确生效（如内部方法调用绕过代理），致使操作未提交。此外，数据源配置错误、SqlSessionTemplate与MyBatis映射不匹配，或使用了readOnly事务也会导致写操作失效。

Answer 1

Spring Boot整合MyBatis中CURD操作无反应问题深度解析

1. 问题现象与初步排查

在Spring Boot整合MyBatis的项目开发中，开发者常遇到如下现象：Service层调用Mapper的insert、update等方法，控制台日志显示SQL语句已成功输出，但数据库中的数据并未发生任何变化，且程序未抛出任何异常。

此类问题具有较强的隐蔽性，往往在测试环境或生产环境中突然暴露，影响系统数据一致性。初步排查方向应包括：

• 确认是否启用了事务管理（@EnableTransactionManagement）
• 检查@Service类或方法上是否添加了@Transactional注解
• 查看日志中是否存在“Rolling back”回滚提示
• 验证数据源配置是否指向正确的数据库实例
• 确认MyBatis映射文件或注解SQL语法是否正确

2. 核心原因分析：事务未生效的典型场景

尽管SQL执行日志可见，但若事务未正确提交，数据库变更将不会持久化。以下是导致事务失效的常见技术原因：

原因分类	具体表现	触发条件
缺少@Transactional	Service方法执行后自动回滚	未标注事务注解，使用默认传播行为REQUIRED_NEW失败
内部方法调用绕过代理	AOP代理未切入，事务不生效	this.method()直接调用，非Bean代理调用
readOnly设置为true	写操作被忽略或静默失败	@Transactional(readOnly = true)误用于更新方法
异常被捕获未抛出	事务无法感知错误状态	try-catch吞掉RuntimeException
代理模式限制	CGLIB或JDK动态代理未正确生成	final方法、private方法、非public方法无法被代理

3. 深度机制剖析：Spring事务代理原理与MyBatis集成路径

Spring通过AOP创建代理对象实现声明式事务管理。当调用@Service Bean的方法时，实际调用的是由CGLIB或JDK动态代理生成的子类/代理类，该代理类在方法前后织入事务逻辑。

然而，若在同一个Service类中，一个非事务方法调用另一个带@Transactional的方法（如this.save()），则调用发生在目标对象自身，绕过了代理，导致事务切面未被触发。

@Service
public class UserService {
    
    public void businessProcess() {
        saveUser(); // ❌ this引用调用，事务不生效
    }

    @Transactional
    public void saveUser() {
        userMapper.insert(new User("Tom"));
    }
}
    

解决方案包括：通过ApplicationContext获取自身Bean、使用AopContext.currentProxy()、或将逻辑拆分至不同Service类。

4. 数据源与SqlSession集成问题排查

即使事务配置正确，若底层数据源或SqlSession配置异常，仍可能导致写操作“看似成功”实则无效。

• 多数据源配置错乱：@Primary缺失或DataSource路由错误，导致操作了只读副本库
• SqlSessionTemplate配置不当：与SqlSessionFactory未绑定同一DataSource
• 连接池自动提交设置：Connection.setAutoCommit(true)可能绕过Spring事务控制
• MyBatis缓存干扰：一级缓存未刷新，导致后续查询返回旧值造成“未更新”假象

5. 可视化诊断流程图

graph TD
            A[CURD操作无数据变化] --> B{是否有@Transactional?}
            B -- 否 --> C[添加@Transactional注解]
            B -- 是 --> D{方法是否被代理调用?}
            D -- 否 --> E[避免this调用或启用expose-proxy]
            D -- 是 --> F{readOnly=false?}
            F -- 是 --> G[移除readOnly或单独标注]
            F -- 否 --> H{异常被捕获?}
            H -- 是 --> I[重新抛出运行时异常]
            H -- 否 --> J{数据源配置正确?}
            J -- 否 --> K[修正application.yml DataSource]
            J -- 是 --> L[检查数据库权限与网络连通性]

6. 实战解决方案汇总

1. 确保主启动类上添加@EnableTransactionManagement
2. 在写操作的Service方法或类上明确标注@Transactional
3. 避免在同一个类中进行this.method()的内部调用
4. 设置spring.jpa.open-in-view=false防止会话延迟关闭问题
5. 启用事务日志：logging.level.org.springframework.transaction=DEBUG
6. 验证数据源URL、用户名、密码及驱动类名正确性
7. 使用@Transactional(propagation = Propagation.REQUIRES_NEW)强制新事务测试
8. 在测试中手动transactionManager.commit()验证连接有效性
9. 排查MyBatis的Executor类型是否为SimpleExecutor而非BatchExecutor误用
10. 启用MyBatis日志：logging.level.mapper.package=DEBUG确认参数绑定正确

7. 高级调试技巧与监控建议

对于复杂微服务架构，建议引入以下手段提升可观察性：

• 使用P6Spy或datasource-proxy监听真实SQL执行与提交行为
• 结合Spring Boot Actuator + Metrics监控事务提交/回滚次数
• 在关键Service方法前后打印TransactionSynchronizationManager.isActualTransactionActive()
• 利用@EventListener监听ApplicationEvent如TransactionalEventListener
• 在集成测试中使用@DirtiesContext和@Rollback(false)验证持久化效果