現代のJavaバックエンド開発では、Spring BootとMyBatis-Plusの組み合わせが広く採用されています。特にデータ操作におけるCRUD処理を簡潔かつ効率的に実現できる点が評価され、その中でも「論理削除」は重要な機能の一つです。

論理削除とは何か？

従来の物理削除（DELETE FROM table WHERE ...）はデータを完全に消去しますが、実務上は削除されたデータが必要になるケースが多々あります。例えば監査ログ、復元要求、統計分析などです。そこで登場するのが「論理削除」——データベース上ではレコードを残しつつ、アプリケーションからは見えなくする仕組みです。

具体的には、テーブルにis_deletedやdeleted_flagといったステータスカラムを追加し、値が0なら有効、1なら削除済みとみなす方式が一般的です。MyBatis-Plusはこのパターンを標準でサポートしており、最小限の設定で自動的にSQLに条件を付与してくれます。

環境設定と基本構成

まず、プロジェクトに必要な依存を追加します：

<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version>
</dependency>

次に、application.ymlでグローバル設定を行います：

mybatis-plus:
  global-config:
    db-config:
      logic-delete-field: isRemoved     # エンティティ内のフィールド名
      logic-not-delete-value: 0         # 未削除状態の値
      logic-delete-value: 1             # 削除状態の値
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

エンティティクラスの定義

対象テーブルにis_removedカラム（INT型、デフォルト0）がある前提で、エンティティにマッピングします：

@Data
@TableName("users")
public class User {
    private Long id;
    private String name;
    
    @TableLogic
    private Integer isRemoved; // 論理削除フラグ
}

@TableLogicアノテーションを付けることで、このフィールドが論理削除用であることをMyBatis-Plusに伝えます。グローバル設定と併用可能で、個別テーブルごとにカスタマイズしたい場合にも柔軟に対応できます。

実際の操作と生成されるSQL

通常通りMapperやServiceを呼び出すだけで、自動的に論理削除が適用されます：

// SELECT 時 → WHERE is_removed = 0 が自動追加
List<User> users = userService.list();

// DELETE 時 → UPDATE users SET is_removed = 1 WHERE id = ? AND is_removed = 0
userService.removeById(123L);

つまり、removeById()のような削除メソッドを呼んでも、実際にはUPDATE文が発行され、is_removedカラムの値が1に変更されるだけです。これにより、データは物理的には残りつつ、アプリケーションからは非表示になります。

テーブルごとのカスタマイズ

全テーブルで同じ論理削除フィールドを使わない場合は、@TableLogicに直接値を指定することも可能です：

@TableLogic(value = "false", delval = "true")
private Boolean archived;

このようにすると、archived = falseが有効レコード、trueが削除済みレコードとして扱われます。柔軟な設計が可能で、既存スキーマへの適応もしやすくなります。