MyBatis-Flex 逻辑删除与物理删除的灵活应用

在数据库操作中，删除数据通常分为逻辑删除和物理删除两种方式。逻辑删除通过标记字段（如 is_deleted）来标识数据是否被删除，而物理删除则是直接从数据库中移除数据记录。MyBatis-Flex 提供了强大的逻辑删除功能，同时也支持在特定场景下绕过逻辑删除直接执行物理删除。

逻辑删除的基本配置

MyBatis-Flex 中配置逻辑删除非常简单。在实体类中，可以通过注解或全局配置指定逻辑删除字段：

@Table("tb_account")
public class Account {
    @Column(isLogicDelete = true)
    private Boolean isDeleted;
    // 其他字段...
}

或者在全局配置中指定：

mybatis-flex:
  global-config:
    logic-delete-column: is_deleted

配置完成后，所有通过 MyBatis-Flex 提供的删除方法（如 removeById、deleteByQuery 等）都会自动转换为更新操作，将逻辑删除字段设置为已删除状态。

特殊场景下的物理删除需求

虽然逻辑删除是推荐的做法，但在某些特殊场景下，我们确实需要执行物理删除：

1. 敏感数据需要彻底清除
2. 临时数据不再需要保留
3. 特定业务要求必须物理删除
4. 性能优化考虑（大量历史数据需要清理）

MyBatis-Flex 的解决方案

MyBatis-Flex 提供了两种方式来实现物理删除：

1. 使用 @Table 注解的 ignoreLogicDelete 属性

@Table(value = "tb_account", ignoreLogicDelete = true)
public class Account {
    // 实体类定义
}

这种方式会忽略该实体类所有操作中的逻辑删除处理。

2. 使用 Mapper 的 ignoreLogicDelete 方法

对于更细粒度的控制，可以在执行删除操作时临时忽略逻辑删除：

accountMapper.ignoreLogicDelete()
    .deleteById(1);

或者在查询构建器中使用：

QueryWrapper.create()
    .ignoreLogicDelete()
    .delete();

最佳实践建议

1. 谨慎使用物理删除：物理删除是不可逆操作，建议只在确实必要时使用
2. 权限控制：对物理删除操作进行严格的权限控制
3. 日志记录：记录所有物理删除操作以备审计
4. 事务管理：确保物理删除操作在事务中执行
5. 备份策略：考虑在执行物理删除前进行数据备份

总结

MyBatis-Flex 通过灵活的配置和API设计，既支持了逻辑删除这一最佳实践，又为特殊场景下的物理删除需求提供了解决方案。开发者可以根据实际业务需求，选择最适合的数据删除策略，在数据安全和系统性能之间取得平衡。

在实际项目中，建议将物理删除操作封装在特定的Service方法中，并添加详细的注释说明为何需要物理删除，这样既能满足业务需求，又能保证代码的可维护性。