MyBatis-Plus 在 LoRA 训练任务管理系统中的集成实践
在当前 AIGC 技术迅猛发展的背景下，LoRA（Low-Rank Adaptation）作为一种轻量级模型微调方法，因其对计算资源要求低、适配速度快，已被广泛应用于 Stable Diffusion 图像生成和大语言模型（LLM）的垂直领域定制。为降低使用门槛，社区涌现出如lora-scripts这类自动化训练工具，封装了从数据预处理到权重导出的完整流程。
但当这类脚本进入企业级生产环境时，问题也随之而来：如何管理成百上千个用户的并发训练任务？如何追踪每一个任务的状态变化？服务重启后任务是否会丢失？日志如何归档与回溯？这些都不是简单执行一条 Python 命令就能解决的问题。
真正需要的，是一个具备任务全生命周期管理能力的后台系统——而这正是 MyBatis-Plus 发挥价值的关键场景。
我们构建的这套系统核心目标很明确：把原本“跑完即忘”的命令行脚本，升级为可监控、可恢复、可查询的企业级服务。而实现这一转变的核心环节，就是通过 MyBatis-Plus 实现训练任务的数据持久化与高效访问。
先来看一个最典型的痛点：用户提交了一个 LoRA 训练任务，填写了数据路径、学习率、批次大小等参数。如果只是直接调用python train.py启动进程，一旦服务宕机或部署更新，这个任务就彻底“失联”了。没有状态记录，无法重试，也无法展示进度。
我们的做法是，在接收到请求的第一时间，就将任务信息写入数据库：
@PostMapping("/tasks") public ResponseEntity<String> createTask(@RequestBody TrainTask task) { task.setStatus("PENDING"); task.setCreateTime(LocalDateTime.now()); trainTaskMapper.insert(task); // 一行代码完成持久化 return ResponseEntity.ok("任务已创建，ID: " + task.getId()); }就这么简单的一次insert()调用，却带来了质的变化——哪怕后续训练还没开始，哪怕服务器下一秒重启，这条任务依然存在。系统启动时只需扫描状态为PENDING或RUNNING的记录，就能自动恢复调度逻辑，真正做到“断点续训”。
而支撑这一切的基础，正是 MyBatis-Plus 提供的强大 ORM 能力。它不像 JPA 那样“过度封装”，也不像原生 MyBatis 那样“重复造轮子”。它精准地站在中间位置：保留你对 SQL 的控制权，同时帮你省去那些枯燥无味的样板代码。
比如定义实体类时，只需要加上几个注解：
@TableName("train_task") @Data public class TrainTask { @TableId(type = IdType.AUTO) private Long id; private String taskName; private String modelType; private String status; private Integer batchSize; private Double learningRate; private LocalDateTime createTime; private LocalDateTime updateTime; }然后 Mapper 接口继承一下BaseMapper<TrainTask>，立刻就拥有了insert、selectById、updateById、delete等全套 CRUD 方法，无需任何 XML 文件或额外实现。
更强大的是它的条件构造器。假设前端要查“最近三天内所有正在运行的 SD 模型训练任务”，传统方式可能得拼字符串，容易出错还可能存在注入风险。而在 MyBatis-Plus 中，可以这样写：
QueryWrapper<TrainTask> wrapper = new QueryWrapper<>(); wrapper.eq("model_type", "SD") .eq("status", "RUNNING") .ge("create_time", LocalDateTime.now().minusDays(3)) .orderByDesc("create_time"); List<TrainTask> tasks = trainTaskMapper.selectList(wrapper);链式调用清晰直观，类型安全，还能自动转义特殊字符，从根本上杜绝 SQL 注入问题。而且后期加筛选条件也非常方便，比如再加个“按任务名模糊搜索”，只需.like("task_name", keyword)即可。
对于分页这种高频需求，MyBatis-Plus 也提供了极简方案。配合拦截器配置：
@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }之后就可以直接使用：
Page<TrainTask> page = new Page<>(pageNum, pageSize); Page<TrainTask> result = trainTaskMapper.selectPage(page, null);返回的结果自带总条数、当前页数据、是否首页/末页等信息，前端分页组件可以直接消费。整个过程透明且高效，底层会根据数据库类型自动生成对应的LIMIT offset, size或ROW_NUMBER()查询。
当然，在实际系统中，任务管理远不止增删改查这么简单。我们还需要考虑并发控制、状态一致性、异常恢复等问题。
举个例子：多个线程同时尝试启动同一个 PENDING 状态的任务怎么办？这就需要事务保护：
@Transactional public boolean tryStartTask(Long taskId) { TrainTask task = trainTaskMapper.selectById(taskId); if (!"PENDING".equals(task.getStatus())) { return false; // 已被其他线程抢走 } task.setStatus("RUNNING"); task.setProcessId(getCurrentPythonPid()); // 记录子进程 ID trainTaskMapper.updateById(task); startTrainingProcessAsync(task); // 异步启动训练脚本 return true; }加上@Transactional注解后，整个读取-判断-更新操作在一个事务内完成，避免了竞态条件。即使高并发下也能保证每个任务只被调度一次。
另一个关键设计是日志采集与状态同步。训练脚本运行过程中会产生大量日志，我们需要从中提取 Loss 变化、当前 epoch、GPU 利用率等指标，并实时更新到数据库。但由于日志解析较耗时，不能阻塞主请求线程。
解决方案是启用独立的监控线程池，定期轮询所有 RUNNING 状态的任务，读取其log_path文件末尾几行，进行结构化解析：
ScheduledFuture<?> future = scheduler.scheduleAtFixedRate(() -> { List<TrainTask> runningTasks = trainTaskMapper.selectList( new QueryWrapper<TrainTask>().eq("status", "RUNNING") ); for (TrainTask task : runningTasks) { LogMetrics metrics = parseLatestLog(task.getLogPath()); if (metrics.isFinished()) { updateTaskStatus(task.getId(), "SUCCESS"); } else if (metrics.hasError()) { updateTaskStatus(task.getId(), "FAILED", metrics.getErrorMsg()); } else { updateTaskProgress(task.getId(), metrics.getEpoch(), metrics.getLoss()); } } }, 0, 10, TimeUnit.SECONDS);这种方式既不影响主流程性能，又能实现近实时的状态反馈。前端页面每隔几秒拉一次/api/tasks，就能看到动态刷新的训练进度条。
至于数据库层面的设计，我们也积累了一些经验：
CREATE TABLE train_task ( id BIGINT AUTO_INCREMENT PRIMARY KEY, task_name VARCHAR(255) NOT NULL, model_type ENUM('SD', 'LLM') DEFAULT 'SD', batch_size INT, learning_rate DOUBLE, status VARCHAR(50) DEFAULT 'PENDING', process_id BIGINT COMMENT '对应 Python 子进程 PID', log_path TEXT, output_dir TEXT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_status (status), INDEX idx_create_time (create_time) );status字段建立索引，确保状态查询高效；process_id记录操作系统级 PID，支持管理员手动终止任务；TEXT类型用于存储长路径，避免字段长度不足；- 时间字段默认值 + 自动更新，减少代码中手动赋值；
- 所有变更都触发
update_time更新，便于排查问题。
值得一提的是，MyBatis-Plus 的UpdateWrapper在部分更新场景下非常实用。例如只想更新任务状态而不影响其他字段：
UpdateWrapper<TrainTask> wrapper = new UpdateWrapper<>(); wrapper.eq("id", taskId) .set("status", "FAILED") .set("log_path", errorLogPath); trainTaskMapper.update(null, wrapper);相比先查后改的方式，减少了数据库交互次数，也避免了中间状态被修改的风险。
此外，开发阶段开启性能分析插件也非常有帮助：
if ("dev".equals(profile)) { interceptor.addInnerInterceptor(new PerformanceInnerInterceptor()); }它会在控制台打印每条 SQL 的执行时间和执行计划，快速定位慢查询。曾经我们就发现某个列表接口耗时高达 800ms，启用该插件后立即发现问题出在一个未加索引的模糊查询上，添加索引后降至 30ms 以内。
最后想强调一点：技术选型的背后其实是工程权衡。为什么选择 MyBatis-Plus 而不是 JPA？
因为我们在实践中发现，AI 训练系统的查询模式复杂多变——不仅要查任务状态，还要统计成功率、分析训练时长分布、关联用户权限、做多维筛选。JPA 的 JPQL 在面对这些需求时显得笨重，而 MyBatis-Plus 既能用 Wrapper 快速搞定简单查询，又能在必要时轻松切换到自定义 SQL 解决复杂联表或聚合分析，灵活性更高。
更重要的是，团队成员普遍熟悉 SQL，调试起来更直观。毕竟在排查一个失败任务的原因时，没人愿意去看 Hibernate 生成的几十行嵌套 HQL。
如今，这套基于 MyBatis-Plus 构建的任务管理系统已在多个客户环境中稳定运行，支撑着每日数百个 LoRA 任务的调度与监控。从前端可视化界面到后端高可用架构，每一层都得益于数据层的坚实支撑。
未来我们计划在此基础上引入 Spring Batch 实现批量任务编排，结合 Quartz 支持定时训练，甚至接入 Airflow 打造统一的 AI 模型训练中台。但无论上层如何演进，MyBatis-Plus 作为连接业务逻辑与数据存储的桥梁，其核心地位短期内不会改变。
因为它所做的，不只是简化 CRUD，而是让开发者能把精力真正聚焦在“如何更好地管理 AI 训练任务”这件事本身，而不是陷在数据库操作的细节里。这或许就是优秀框架的最大价值。
)
