## モジュール 3: TiKV MVCC インメモリエンジンの利用による検索パフォーマンス向上します

本モジュールでは、まず、定義、データ、および MVCC 履歴スナップショットが同じ 2 つのテーブルを作成します。これらの 2 つのテーブルは、以前に定義された PLACEMENT POLICY に基づいて、LEADER 役割の Region データを 2 つの異なる TiKV ノードに配置します。1 つの TiKV ノードは TiKV MVCC メモリエンジンの特性を有効にし、もう 1 つは無効にしています。受講者はそれぞれこの 2 つのテーブルに対してインデックススキャンとテーブルスキャンの 2 種類の操作を行い、監視結果を観察することで TiKV MVCC メモリエンジンの特性が性能向上に与える影響を比較します。

### 手順 1. TiUP コントロールマシンに2つのターミナルで接続します

+ 以下のリンクをクリックして、演習用仮想マシンへの2つのSSH接続を開きます：
  + [ターミナル 1](ssh://monitor1-ssh#1)
  + [ターミナル 2](ssh://monitor1-ssh#2)

+ これで2つのアクティブなターミナルセッションが開かれます。

### 手順 2. テーブルの作成

+ [ターミナル 1](ssh://monitor1-ssh#1) で、TiDBサーバーインスタンスに接続します。

  ```bash
  mysql -h ${HOST_DB1_PRIVATE_IP} --port 4000 -u root
  ```

  ```output
  mysql> 
  ```

+ [ターミナル 1](ssh://monitor1-ssh#1) で、`test` の下に `tbl_no_ime_R1` および `tbl_ime_R2` のテーブルを作成し、テーブル作成に使用される DDL ステートメントについて理解します。

  ```sql
  DROP TABLE IF EXISTS test.tbl_ime_R1;
  CREATE TABLE test.tbl_ime_R1 (
  `ID` bigint (20) NOT NULL AUTO_INCREMENT,
  `pID` bigint (20) NOT NULL,
  `cID` bigint (20) NOT NULL,
  `sID` bigint (20) NOT NULL,
  `pState` varchar (100) NOT NULL,
  `cState` tinyint (4) DEFAULT NULL,
  `created_at` DATETIME,
  `updated_at` DATETIME,
  `txt` varchar(64) DEFAULT 'IMETEST',
  PRIMARY KEY (`sID`, `ID`),
  UNIQUE KEY `pcsID` (`pID`, `cID`, `sID`),
  KEY `pcStateIndex` (`pState`, `cState`)
  ) PLACEMENT POLICY = IME_R1;

  DROP TABLE IF EXISTS test.tbl_ime_R2;
  CREATE TABLE test.tbl_ime_R2 (
  `ID` bigint (20) NOT NULL AUTO_INCREMENT,
  `pID` bigint (20) NOT NULL,
  `cID` bigint (20) NOT NULL,
  `sID` bigint (20) NOT NULL,
  `pState` varchar (100) NOT NULL,
  `cState` tinyint (4) DEFAULT NULL,
  `created_at` DATETIME,
  `updated_at` DATETIME,
  `txt` varchar(64) DEFAULT 'IMETEST',
  PRIMARY KEY (`sID`, `ID`),
  UNIQUE KEY `pcsID` (`pID`, `cID`, `sID`),
  KEY `pcStateIndex` (`pState`, `cState`)
  ) PLACEMENT POLICY = IME_R2;

  EXIT;
  ```

  ```output
  mysql> CREATE TABLE test.tbl_ime_R1 (
      -> `ID` bigint (20) NOT NULL AUTO_INCREMENT,
      -> `pID` bigint (20) NOT NULL,
      -> `cID` bigint (20) NOT NULL,
      -> `sID` bigint (20) NOT NULL,
      -> `pState` varchar (100) NOT NULL,
      -> `cState` tinyint (4) DEFAULT NULL,
      -> `created_at` DATETIME,
      -> `updated_at` DATETIME,
      -> `txt` varchar(64) DEFAULT 'IMETEST',
      -> PRIMARY KEY (`sID`, `ID`),
      -> UNIQUE KEY `pcsID` (`pID`, `cID`, `sID`),
      -> KEY `pcStateIndex` (`pState`, `cState`)
      -> ) PLACEMENT POLICY = IME_R1;
  Query OK, 0 rows affected, 5 warnings (0.52 sec)

  mysql> 
  mysql> DROP TABLE IF EXISTS test.tbl_ime_R2;
  Query OK, 0 rows affected, 1 warning (0.00 sec)

  mysql> CREATE TABLE test.tbl_ime_R2 (
      -> `ID` bigint (20) NOT NULL AUTO_INCREMENT,
      -> `pID` bigint (20) NOT NULL,
      -> `cID` bigint (20) NOT NULL,
      -> `sID` bigint (20) NOT NULL,
      -> `pState` varchar (100) NOT NULL,
      -> `cState` tinyint (4) DEFAULT NULL,
      -> `created_at` DATETIME,
      -> `updated_at` DATETIME,
      -> `txt` varchar(64) DEFAULT 'IMETEST',
      -> PRIMARY KEY (`sID`, `ID`),
      -> UNIQUE KEY `pcsID` (`pID`, `cID`, `sID`),
      -> KEY `pcStateIndex` (`pState`, `cState`)
      -> ) PLACEMENT POLICY = IME_R2;
  Query OK, 0 rows affected, 5 warnings (0.52 sec)

  mysql> 
  mysql> EXIT;
  Bye
  ```

+ テーブル作成の DDL ステートメントにおける PLACEMENT POLICY の定義により、以下のことがわかります：
  + テーブル `tbl_ime_R1` の PLACEMENT POLICY は `IME_R1` であり、すべての LEADER 役割 Region が `region1` の TiKV ノードに格納されていることを示します。そのため、行う読み書きもデフォルトで `region1` の TiKV ノードで行われます。
  + テーブル `tbl_ime_R2` の PLACEMENT POLICY は `IME_R2` であり、すべての LEADER 役割 Region が `region2` の TiKV ノードに格納されていることを示します。そのため、行う読み書きもデフォルトで `region2` の TiKV ノードで行われます。
  + テーブル `tbl_ime_R1` と `tbl_ime_R2` の TiKV クラスター内のストレージは以下の図のようになります：

  ![IME_PART2_TABLES_5.png 70%](https://lab-static.pingcap.com/images/2025/8/20/05cea87a3e752536c404e0a246e6e72afcf7960c.png)

### 手順 3. データを準備します

+ [ターミナル 1](ssh://monitor1-ssh#1) で、TiDBサーバーインスタンスに接続します。

  ```bash
  mysql -h ${HOST_DB1_PRIVATE_IP} --port 4000 -u root
  ```

  ```output
  mysql> 
  ```

+ [ターミナル 1](ssh://monitor1-ssh#1) で、2 つのシーケンス（SEQUENCE）オブジェクト、`test.seq_ime_R1` および  `test.seq_ime_R2` を作成し、次にテーブル `test.tbl_ime_R1` および `test.tbl_ime_R2` にデータを挿入する際に使用します。

  ```sql
  DROP SEQUENCE IF EXISTS test.seq_ime_R1;
  CREATE SEQUENCE test.seq_ime_R1;
  DROP SEQUENCE IF EXISTS test.seq_ime_R2;
  CREATE SEQUENCE test.seq_ime_R2;
  EXIT
  ```

  ```output
  mysql> DROP SEQUENCE IF EXISTS test.seq_ime_R1;
  Query OK, 0 rows affected (0.51 sec)

  mysql> CREATE SEQUENCE test.seq_ime_R1;
  Query OK, 0 rows affected (0.52 sec)

  mysql> DROP SEQUENCE IF EXISTS test.seq_ime_R2;
  Query OK, 0 rows affected (0.51 sec)

  mysql> CREATE SEQUENCE test.seq_ime_R2;
  Query OK, 0 rows affected (0.52 sec)

  mysql> EXIT
  Bye
  ```

+ [ターミナル 1](ssh://monitor1-ssh#1) で、`tiup bench` ツールを使用してテーブル `test.tbl_ime_R1` に 1,000 行のランダムデータを挿入します。各行のデータを挿入した後、その行に対して 10 回の更新操作（UPDATE）を行い、10 個の MVCC スナップショットを生成します。これには約 1 分かかります。

  ```bash
  cat > tbl_ime_query_R1.sql <<EOF
  SELECT @sID := 200001 + FLOOR(RAND() * 99999);
  INSERT INTO test.tbl_ime_R1 (pID, cID, sID, pState, cState, created_at, updated_at) VALUES (1 + FLOOR(RAND() * 99999), 100001 + FLOOR(RAND() * 99999), @sID, ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), 1 + FLOOR(RAND() * 29), NOW(), NOW());
  SELECT @ID := NEXTVAL(test.seq_ime_R1);
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  UPDATE test.tbl_ime_R1 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID;
  EOF
  tiup bench rawsql run -H ${HOST_DB1_PRIVATE_IP} -P 4000 --count 1000 --threads 1 --query-files tbl_ime_query_R1.sql
  ```

  ```output
  Starting component bench: /home/ec2-user/.tiup/components/bench/v1.12.0/tiup-bench rawsql run -H 10.90.1.40 -P 4000 --count 1000 --threads 1 --query-files tbl_ime_query_R1.sql
  [Current] TBL_IME_QUERY_R1: 0.00s
  [Current] TBL_IME_QUERY_R1: 0.00s
  [Current] TBL_IME_QUERY_R1: 0.00s
  [Current] TBL_IME_QUERY_R1: 0.00s
  [Current] TBL_IME_QUERY_R1: 0.00s
  Finished
  [Summary] TBL_IME_QUERY_R1: 0.00s
  ```

+ [ターミナル 1](ssh://monitor1-ssh#1) で、`tiup bench` ツールを使用してテーブル `test.tbl_ime_R2` に 1,000 行のランダムデータを挿入します。各行のデータを挿入した後、その行に対して 10 回の更新操作（UPDATE）を行い、10 個の MVCC スナップショットを生成します。これには約 1 分かかります。

  ```bash
  cat > tbl_ime_query_R2.sql <<EOF
  SELECT @sID := 200001 + FLOOR(RAND() * 99999);
  INSERT INTO test.tbl_ime_R2 (pID, cID, sID, pState, cState, created_at, updated_at) VALUES (1 + FLOOR(RAND() * 99999), 100001 + FLOOR(RAND() * 99999), @sID, ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), 1 + FLOOR(RAND() * 29), NOW(), NOW());
  SELECT @ID := NEXTVAL(test.seq_ime_R2);
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  UPDATE test.tbl_ime_R2 SET pState = ELT(1 + FLOOR(RAND() * 9), 's1', 's2', 's3', 's4', 's5', 's6', 's7', 's8', 's9', 's0'), cState = 1 + FLOOR(RAND() * 29) WHERE sID = @sID AND ID = @ID; 
  EOF
  tiup bench rawsql run -H ${HOST_DB1_PRIVATE_IP} -P 4000 --count 1000 --threads 1 --query-files tbl_ime_query_R2.sql
  ```

  ```output
  Starting component bench: /home/ec2-user/.tiup/components/bench/v1.12.0/tiup-bench rawsql run -H 10.90.1.40 -P 4000 --count 1000 --threads 1 --query-files tbl_ime_query_R2.sql
  [Current] TBL_IME_QUERY_R2: 0.00s
  [Current] TBL_IME_QUERY_R2: 0.00s
  [Current] TBL_IME_QUERY_R2: 0.00s
  [Current] TBL_IME_QUERY_R2: 0.00s
  [Current] TBL_IME_QUERY_R2: 0.00s
  [Current] TBL_IME_QUERY_R2: 0.00s
  Finished
  [Summary] TBL_IME_QUERY_R2: 0.00s
  ```

### 手順 4. インデックススキャンのクエリ性能の向上

+ [ターミナル 1](ssh://monitor1-ssh#1) で、TiDBサーバーインスタンスに接続します。

  ```bash
  mysql -h ${HOST_DB1_PRIVATE_IP} --port 4000 -u root
  ```

  ```output
  mysql> 
  ```

+ [ターミナル 1](ssh://monitor1-ssh#1) で、次の SQL コマンドを実行し、それぞれテーブル `test.tbl_ime_R1` に対してクエリを実行します。

  ```sql
  SELECT sID, ID, txt FROM test.tbl_ime_R1 USE INDEX (pcStateIndex) WHERE ((pState = 's1') OR (pState = 's2') OR (pState = 's3')) OR ((pState = 's3' AND cState = 10) OR (pState = 's3' AND cState = 20)) AND NOT (sID = 200001 AND ID = 1097) AND NOT (sID = 0 AND ID = 0) LIMIT 50;
  ```

  ```output
  +--------+------+---------+
  | sID    | ID   | txt     |
  +--------+------+---------+
  | 200875 | 1425 | IMETEST |
  | 201896 | 2340 | IMETEST |
  ...
  | 296436 | 2098 | IMETEST |
  | 298352 | 2262 | IMETEST |
  +--------+------+---------+
  50 rows in set (0.01 sec)
  EXIT
  ```

+ [ターミナル 1](ssh://monitor1-ssh#1) で、次の SQL コマンドを実行し、それぞれテーブル `test.tbl_ime_R2` に対してクエリを実行します。

  ```sql
  SELECT sID, ID, txt FROM test.tbl_ime_R2 USE INDEX (pcStateIndex) WHERE ((pState = 's1') OR (pState = 's2') OR (pState = 's3')) OR ((pState = 's3' AND cState = 10) OR (pState = 's3' AND cState = 20)) AND NOT (sID = 200001 AND ID = 1097) AND NOT (sID = 0 AND ID = 0) LIMIT 50;
  ```

  ```output
  +--------+-----+---------+
  | sID    | ID  | txt     |
  +--------+-----+---------+
  | 202196 |  91 | IMETEST |
  | 203510 | 375 | IMETEST |
  ...
  | 299728 | 514 | IMETEST |
  | 299902 | 832 | IMETEST |
  +--------+-----+---------+
  50 rows in set (0.00 sec)
  mysql> EXIT
  Bye
  ```

+ [TiDB Dashboard](http://${LAB:HOST_PD1_PUBLIC_IP}:2379/dashboard)にアクセスし、ユーザー名`root`でログインします。現時点ではパスワードは不要です。`SQL Statements`パネルに移動し、表示時間を`Recent 5 min`に変更します。

  ![60%](https://lab-static.pingcap.com/quick-demo/ime-off-dashboard-time-1.png)

+ データベースを`test`に選択します。

  ![60%](https://lab-static.pingcap.com/quick-demo/ime-off-dashboard-db-2.png)

+ 表示される操作を `Select` に設定します。

  ![IME_PART3_DASHBOARD_INDEX_1.png 70%](https://lab-static.pingcap.com/images/2025/8/20/22d376120199a59922852df88503485e6e666be4.png)

+ 先ほど実行したクエリのテーブル `test.tbl_ime_R1` の SQL コマンド（実行回数は 1）を選択し、クリックして詳細を確認します。

  ![IME_PART3_DASHBOARD_INDEX_2.png 70%](https://lab-static.pingcap.com/images/2025/8/20/a80f9ac47d2356173879fc28ef998fac0821c560.png)

+ `Execution Detail` の `Execution Plan` 項目を確認し、オペレーター `IndexLookUp_14` に基づいて、このクエリがインデックススキャンを使用していることを確認します。次に、オペレーター `Limit_13(Build)` を見つけ、その `Execution Info` 情報を確認すると、`total_process_keys` が `96`、`total_keys` が `2193` であることがわかります。これは、テーブル内でスキャンしてフィルタリングする必要のある行数が、実際に保存されている総行数よりもはるかに少ないことを示しており、このクエリは TiKV MVCC メモリエンジンを使用してクエリ性能を向上させるのに適していることを示しています。（出力結果は若干異なる場合があります）

  ![IME_PART3_DASHBOARD_INDEX_3.png 70%](https://lab-static.pingcap.com/images/2025/8/20/9db33fbe6b450f2d5797c07c7d739218b087d975.png)

+ 先ほど実行したクエリのテーブル `test.tbl_ime_R2` の SQL コマンド（実行回数は 1）を選択し、クリックして詳細を確認します。

  ![IME_PART3_DASHBOARD_INDEX_4.png 70%](https://lab-static.pingcap.com/images/2025/8/20/5de60326bf7ec54e6f7dd7cb2706e70bede561ff.png)

+ `Execution Detail` の `Execution Plan` 項目を確認すると、その実行計画は前の SQL コマンドと同じで、両方ともインデックススキャンオペレーターを使用していることがわかります。以下の図のようになります：

  ![IME_PART3_DASHBOARD_INDEX_5.png 70%](https://lab-static.pingcap.com/images/2025/8/20/7110b4053fa2dc3145d44e578fa54d9b2bff182a.png)

+ [ターミナル 2](ssh://monitor1-ssh#2) で、`tiup bench` ツールを使用してテーブル `test.tbl_ime_R1` をスキャンします。スキャンは継続的に行われるため、スキャンが終了するのを待たずにすぐに次の操作を実行してください。（テーブルのスキャンはおおよそ3~5分間続きます。）

  ```bash
  cat > index_scan_tbl_ime_R1.sql <<EOF
  SELECT sID, ID, txt FROM test.tbl_ime_R1 USE INDEX (pcStateIndex) WHERE ((pState = 's1') OR (pState = 's2') OR (pState = 's3')) OR ((pState = 's3' AND cState = 10) OR (pState = 's3' AND cState = 20)) AND NOT (sID = 200001 AND ID = 1097) AND NOT (sID = 0 AND ID = 0) LIMIT 50;
  EOF
  tiup bench rawsql run -H ${HOST_DB1_PRIVATE_IP} -P 4000 --count 100000 --threads 1 --query-files index_scan_tbl_ime_R1.sql
  ```

  ```output
  Starting component bench: /home/ec2-user/.tiup/components/bench/v1.12.0/tiup-bench rawsql run -H 10.90.1.40 -P 4000 --count 100000 --threads 1 --query-files index_scan_tbl_ime_R1.sql
  [Current] INDEX_SCAN_TBL_IME_R1: 0.00s
  [Current] INDEX_SCAN_TBL_IME_R1: 0.00s
  ...
  ```

+ [Grafana dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000)にログインし、監視の時間範囲を最近15分に設定し、更新頻度を5秒に変更することをお勧めします。

  ![IME_PART3_TiKV_DETAIL_INDEX_1.png 70%](https://lab-static.pingcap.com/images/2025/8/20/de118edc706857e83407e65968e1a7be7eca79dc.png)

+ `tidb-demo-TiKV-Details` の `In Memory Engine` タブでは、`Region Cache Hit`、`Region Cache Hit Rate`、および `Region Cache Miss Reason` パネルを通じて、現在 `region1` の TiKV ノードが TiKV MVCC メモリエンジンを有効にしていないため表示されないことがわかります。このため、現在のクエリは TiKV MVCC メモリエンジンを使用していません。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_INDEX_2.png 70%](https://lab-static.pingcap.com/images/2025/8/20/4c1bf579870186fd2737072fda121448992c9473.png)

+ `tidb-demo-TiKV-Details` の `Coprocessor Detail` タブでは、`Total Ops Details by CF (Index Scan)` パネルを通じて、現在 `region1` の TiKV ノードのコプロセッサにおける RocksDB の各 CF に対するインデックスのスキャン中に発生するさまざまなイベントの発生率を確認できます（`Total Ops Details by CF (Index Scan)` パネルは、インデックス読み取りを実行する際に RocksDB の Column Family (CF) に送信されるイベント数を毎秒表示し、ユーザーはこれを通じてインデックス読み取り時のストレージ層の負荷を監視できます）。例えば、`write-next` イベントは約 400K ops/m 以上、`write-processed_keys` イベントは約 20.0K ops/m 以上です。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_INDEX_3.png 70%](https://lab-static.pingcap.com/images/2025/8/20/ad42056f7be0ad77f4d4aad46c40b631bb421b15.png)

+ `tidb-demo-TiKV-Details` の `gRPC` タブでは、`99% gRPC message duration` パネルを通じて（`99% gRPC message duration` パネルは、99% の TiKV 各種メッセージの単位時間内の最大遅延を表示し、特定のタイプのメッセージ（例えば `coprocessor`、`kv_commit` など）の処理における性能ボトルネックを特定するのに役立ちます）、現在の `coprocessor` の実行における 99% の実行遅延が約 `1ms` の範囲にあることがわかります。以下の図のようになります（図例の `coprocessor` タブをクリックすると、より詳細に確認できます）：

  ![IME_PART3_TiKV_DETAIL_INDEX_4.png 70%](https://lab-static.pingcap.com/images/2025/8/20/d73a6268beaffed0ea5a8c2d3062bd9b6cca4d03.png)

+ [ターミナル 2](ssh://monitor1-ssh#2) で、テーブル `test.tbl_ime_R1` のスキャンが終了するのを待つか、**CTRL-C**を押してスキャンを終了します。

  ```output
  ...
  [Current] INDEX_SCAN_TBL_IME_R1: 0.00s
  [Current] INDEX_SCAN_TBL_IME_R1: 0.00s
  Finished
  [Summary] INDEX_SCAN_TBL_IME_R1: 0.00s
  ```

+ 再度 [Grafana dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) に戻り、`tidb-demo-TiKV-Details` の `Coprocessor Detail` タブでは、`Total Ops Details by CF (Index Scan)` パネルにおいて関連イベントの発生率が下降し始めていることを観察しました。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_INDEX_5.png 70%](https://lab-static.pingcap.com/images/2025/8/20/5fca4b2f57d7b76f7dfa22c740709c6e8a77af14.png)

+ `tidb-demo-TiKV-Details` の `gRPC` タブでは、`99% gRPC message duration` において `coprocessor` の実行に関する 99% の実行遅延が下降し始めていることを観察しました。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_INDEX_6.png 70%](https://lab-static.pingcap.com/images/2025/8/20/31bc2eb6a9131c047094ea3d43541b8cb423a9f0.png)

+ [ターミナル 2](ssh://monitor1-ssh#2) で、`tiup bench` ツールを使用してテーブル `test.tbl_ime_R2` をスキャンします。スキャンは継続的に行われるため、スキャンが終了するのを待たずにすぐに次の操作を実行してください。（テーブルのスキャンはおおよそ3~5分間続く予定です。）

  ```bash
  cat > index_scan_tbl_ime_R2.sql <<EOF
  SELECT sID, ID, txt FROM test.tbl_ime_R2 USE INDEX (pcStateIndex) WHERE ((pState = 's1') OR (pState = 's2') OR (pState = 's3')) OR ((pState = 's3' AND cState = 10) OR (pState = 's3' AND cState = 20)) AND NOT (sID = 200001 AND ID = 1097) AND NOT (sID = 0 AND ID = 0) LIMIT 50;
  EOF
  tiup bench rawsql run -H ${HOST_DB1_PRIVATE_IP} -P 4000 --count 100000 --threads 1 --query-files index_scan_tbl_ime_R2.sql
  ```

  ```output
  Starting component bench: /home/ec2-user/.tiup/components/bench/v1.12.0/tiup-bench rawsql run -H 10.90.1.40 -P 4000 --count 100000 --threads 1 --query-files index_scan_tbl_ime_R2.sql
  [Current] INDEX_SCAN_TBL_IME_R2: 0.00s
  [Current] INDEX_SCAN_TBL_IME_R2: 0.00s
  ...
  ```

+ 再度 [Grafana dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) に戻り、`tidb-demo-TiKV-Details` の `In Memory Engine` タブでは、`Region Cache Hit`、`Region Cache Hit Rate`、および `Region Cache Miss Reason` パネルを通じて、現在 `region2` の TiKV ノードが TiKV MVCC メモリエンジンを使用しており、`Region Cache Hit Rate` が `100%` に近いことがわかりました。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_INDEX_7.png 70%](https://lab-static.pingcap.com/images/2025/8/20/8e57d8b9c4b106f92d77df6a98976e798f7166c5.png)

+ `tidb-demo-TiKV-Details` の `Coprocessor Detail` タブでは、`Total Ops Details by CF (Index Scan)` パネルを通じて、現在 `region2` の TiKV ノードのコプロセッサにおいて、RocksDB の各 CF に対するインデックスのスキャン中に発生するさまざまなイベントの発生率を確認しました。例えば、`write-next` イベントは約 30K ops/m ～ 40K ops/m、`write-processed_keys` イベントは約 30K ops/m ～ 40K ops/m です。`region1` の TiKV ノードで TiKV MVCC メモリエンジンを使用していなかった前回のクエリと比較して、`write-next` イベントの発生率は大幅に低下しています。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_INDEX_8.png 70%](https://lab-static.pingcap.com/images/2025/8/20/1cbcfc000927b6e01c90c234f986a9c239439c75.png)

+ `tidb-demo-TiKV-Details` の `gRPC` タブでは、`99% gRPC message duration` パネルを通じて、現在 `coprocessor` の 99% の実行遅延が約 395μs の範囲にあることがわかりました。これは、`region1` の TiKV ノードで TiKV MVCC メモリエンジンを使用していなかった前回のクエリと比較しても低下しています。また、`gRPC message count` パネルにおいて `coprocessor` の頻度が向上しています。以下の図のようになります（図例の `coprocessor` タブをクリックすると、より詳細に確認できます）：

  ![IME_PART3_TiKV_DETAIL_INDEX_9.png 70%](https://lab-static.pingcap.com/images/2025/8/20/16b5a73834e7fc9557a72ec387cc73a31b115566.png)

+ [ターミナル 2](ssh://monitor1-ssh#2) で、テーブル `test.tbl_ime_R2` のスキャンが終了するのを待つか、**CTRL-C**を押してスキャンを終了します。

  ```output
  ...
  [Current] INDEX_SCAN_TBL_IME_R2: 0.00s
  [Current] INDEX_SCAN_TBL_IME_R2: 0.00s
  Finished
  [Summary] INDEX_SCAN_TBL_IME_R2: 0.00s
  ```

+ 再度 [Grafana dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) に戻り、`tidb-demo-TiKV-Details` の `Coprocessor Detail` タブでは、`Total Ops Details by CF (Index Scan)` パネルにおいて関連イベントの発生率が下降し始めていることを観察し、2 回のクエリにおける RocksDB のスキャン状況を比較することができます。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_INDEX_10.png 70%](https://lab-static.pingcap.com/images/2025/8/20/1b0c334b77e4293542a525f0f3b1ac1307959394.png)

+ `tidb-demo-TiKV-Details` の `gRPC` タブでは、`99% gRPC message duration` において `coprocessor` の実行に関する 99% の実行遅延が下降し始めていることを観察し、2 回のクエリの 99% の実行遅延状況を比較することができます。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_INDEX_11.png 70%](https://lab-static.pingcap.com/images/2025/8/20/d9abcad18eeb6866189449368ff1fba09fd27fdc.png)

### 手順 5. テーブルスキャンのクエリ性能の向上

+ [ターミナル 1](ssh://monitor1-ssh#1) で、TiDBサーバーインスタンスに接続します。

  ```bash
  mysql -h ${HOST_DB1_PRIVATE_IP} --port 4000 -u root
  ```

  ```output
  mysql> 
  ```

+ [ターミナル 1](ssh://monitor1-ssh#1) で、次の SQL コマンドを実行し、それぞれテーブル `test.tbl_ime_R1` に対してクエリを実行します。

  ```sql
  SELECT sID, ID, txt FROM test.tbl_ime_R1 IGNORE INDEX (pcStateIndex, pcsID) WHERE ((pState = 's1') OR (pState = 's2') OR (pState = 's3')) OR ((pState = 's3' AND cState = 10) OR (pState = 's3' AND cState = 20)) AND NOT (sID = 200001 AND ID = 1097) AND NOT (sID = 0 AND ID = 0) LIMIT 50;
  ```

  ```output
  +--------+------+---------+
  | sID    | ID   | txt     |
  +--------+------+---------+
  | 200208 | 3411 | IMETEST |
  | 200228 | 1097 | IMETEST |
  ...
  | 202804 |   46 | IMETEST |
  | 202820 | 2306 | IMETEST |
  +--------+------+---------+
  50 rows in set (0.01 sec)
  ```

+ [ターミナル 1](ssh://monitor1-ssh#1) で、次の SQL コマンドを実行し、それぞれテーブル `test.tbl_ime_R2` に対してクエリを実行します。

  ```sql
  SELECT sID, ID, txt FROM test.tbl_ime_R2 IGNORE INDEX (pcStateIndex, pcsID) WHERE ((pState = 's1') OR (pState = 's2') OR (pState = 's3')) OR ((pState = 's3' AND cState = 10) OR (pState = 's3' AND cState = 20)) AND NOT (sID = 200001 AND ID = 1097) AND NOT (sID = 0 AND ID = 0) LIMIT 50;
  EXIT
  ```

  ```output
  +--------+-----+---------+
  | sID    | ID  | txt     |
  +--------+-----+---------+
  | 200693 | 554 | IMETEST |
  | 200694 | 200 | IMETEST |
  ...
  | 214020 | 978 | IMETEST |
  | 214956 | 644 | IMETEST |
  +--------+-----+---------+
  50 rows in set (0.00 sec)

  mysql> EXIT
  Bye
  ```

+ [TiDB Dashboard](http://${LAB:HOST_PD1_PUBLIC_IP}:2379/dashboard)にアクセスし、ユーザー名`root`でログインします。現時点ではパスワードは不要です。`SQL Statements`パネルに移動し、表示時間を`Recent 5 min`に変更します。

  ![60%](https://lab-static.pingcap.com/quick-demo/ime-off-dashboard-time-1.png)

+ データベースを`test`に選択します。

  ![60%](https://lab-static.pingcap.com/quick-demo/ime-off-dashboard-db-2.png)

+ 表示される操作を `Select` に設定します。

  ![IME_PART3_DASHBOARD_TABLE_1.png 70%](https://lab-static.pingcap.com/images/2025/8/20/398f59c3dc85baace38caa0341f4c143c2cafc19.png)

+ 先ほど実行したクエリのテーブル `test.tbl_ime_R1` の SQL コマンド（実行回数は 1）を選択し、クリックして詳細を確認します。

  ![IME_PART3_DASHBOARD_TABLE_2.png 70%](https://lab-static.pingcap.com/images/2025/8/20/a064e6e3cf0b6052ab97c490e7b2e6b33cce3103.png)

+ `Execution Detail` の `Execution Plan` 項目を確認し、オペレーター `TableFullScan_10` に基づいて、このクエリがテーブルフルスキャンを使用していることがわかりました（注意：この時点で、2つのSQL実行計画が存在する可能性があります。テーブルフルスキャンを使用したSQL実行計画は、先ほど実行されたものです）。オペレーター `Limit_12` を見つけ、その `Execution Info` 情報を確認すると、`total_process_keys` が `224`、`total_keys` が `1793` であることがわかります。これは、テーブル内でスキャンしてフィルタリングする必要のある行数が、実際に保存されている総行数よりもはるかに少ないことを示しており、このクエリは TiKV MVCC メモリエンジンを使用してクエリ性能を向上させるのに適しています。（出力結果は若干異なる場合があります）

  ![IME_PART3_DASHBOARD_TABLE_3.png 70%](https://lab-static.pingcap.com/images/2025/8/20/c18939929796ede4565f4f3be0ad7edaa4b26267.png)

+ 先ほど実行したクエリのテーブル `test.tbl_ime_R2` の SQL コマンド（実行回数は 1）を選択し、クリックして詳細を確認します。

  ![IME_PART3_DASHBOARD_TABLE_4.png 70%](https://lab-static.pingcap.com/images/2025/8/20/28cfe70c689c307a5f48b8508bd14ffa0e732538.png)

+ `Execution Detail` の `Execution Plan` 項目を確認すると、その実行計画は前の SQL コマンドと同じで、両方ともテーブルフルスキャンオペレーターを使用していることがわかります（注意：この時点で、2つのSQL実行計画が存在する可能性があります。テーブルフルスキャンを使用したSQL実行計画は、先ほど実行されたものです）。以下の図のようになります：

  ![IME_PART3_DASHBOARD_TABLE_5.png 70%](https://lab-static.pingcap.com/images/2025/8/20/ff1c6801cc846790d2ad88d2de7502a9dbf73704.png)

+ [ターミナル 2](ssh://monitor1-ssh#2) で、`tiup bench` ツールを使用してテーブル `test.tbl_ime_R1` をスキャンします。スキャンは継続的に行われるため、スキャンが終了するのを待たずにすぐに次の操作を実行してください。（テーブルのスキャンはおおよそ3~5分間続きます。）

  ```bash
  cat > table_scan_tbl_ime_R1.sql <<EOF
  SELECT sID, ID, txt FROM test.tbl_ime_R1 IGNORE INDEX (pcStateIndex, pcsID) WHERE ((pState = 's1') OR (pState = 's2') OR (pState = 's3')) OR ((pState = 's3' AND cState = 10) OR (pState = 's3' AND cState = 20)) AND NOT (sID = 200001 AND ID = 1097) AND NOT (sID = 0 AND ID = 0) LIMIT 50;
  EOF
  tiup bench rawsql run -H ${HOST_DB1_PRIVATE_IP} -P 4000 --count 100000 --threads 1 --query-files table_scan_tbl_ime_R1.sql
  ```

  ```output
  Starting component bench: /home/ec2-user/.tiup/components/bench/v1.12.0/tiup-bench rawsql run -H 10.90.1.40 -P 4000 --count 100000 --threads 1 --query-files table_scan_tbl_ime_R1.sql
  [Current] TABLE_SCAN_TBL_IME_R1: 0.00s
  [Current] TABLE_SCAN_TBL_IME_R1: 0.00s
  ...
  ```

+ 再度 [Grafana dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) に戻り、`tidb-demo-TiKV-Details` の `In Memory Engine` タブでは、`Region Cache Hit`、`Region Cache Hit Rate`、および `Region Cache Miss Reason` パネルを通じて、現在 `region1` の TiKV ノードが TiKV MVCC メモリエンジンを有効にしていないため表示されないことがわかります。現在のクエリは TiKV MVCC メモリエンジンを使用していません。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_TABLE_2.png 70%](https://lab-static.pingcap.com/images/2025/8/20/eb160f376e4eeeeba5942385b06d4c0aebfa0309.png)

+ `tidb-demo-TiKV-Details` の `Coprocessor Detail` タブでは、`Total Ops Details by CF (Table Scan)` パネルを通じて、現在 `region1` の TiKV ノードのコプロセッサにおいて、RocksDB の各 CF に対するテーブルのスキャン中に発生するさまざまなイベントの発生率を確認しました。例えば、`write-next` イベントは約 400K ops/m 以上、`write-processed_keys` イベントは約 70K ops/m 以上、`write-seek` イベントは約 60K ops/m 以上です。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_TABLE_3.png 70%](https://lab-static.pingcap.com/images/2025/8/20/e0871b4eed23ac0ef4ca21749d51d3bfcaab912c.png)

+ `tidb-demo-TiKV-Details` の `gRPC` タブでは、`99% gRPC message duration` パネルを通じて、現在 `coprocessor` の 99% の実行遅延が約 `1ms` の範囲にあることがわかりました。以下の図のようになります（図例の `coprocessor` タブをクリックすると、より詳細に確認できます）：

  ![IME_PART3_TiKV_DETAIL_TABLE_4.png 70%](https://lab-static.pingcap.com/images/2025/8/20/99e898e6e46febbe133885ff09f910b22828db8a.png)

+ [ターミナル 2](ssh://monitor1-ssh#2) で、テーブル `test.tbl_ime_R1` のスキャンが終了するのを待つか、**CTRL-C**を押してスキャンを終了します。

  ```output
  ...
  [Current] TABLE_SCAN_TBL_IME_R1: 0.00s
  [Current] TABLE_SCAN_TBL_IME_R1: 0.00s
  Finished
  [Summary] TABLE_SCAN_TBL_IME_R1: 0.00s
  ```

+ 再度 [Grafana dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) に戻り、`tidb-demo-TiKV-Details` の `Coprocessor Detail` タブでは、`Total Ops Details by CF (Table Scan)` パネルにおいて関連イベントの発生率が下降し始めていることを観察しました。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_TABLE_5.png 70%](https://lab-static.pingcap.com/images/2025/8/20/34e236c12adf4de7dd80c37b59dc82a0df74ee9d.png)

+ `tidb-demo-TiKV-Details` の `gRPC` タブでは、`99% gRPC message duration` において `coprocessor` の実行に関する 99% の実行遅延が下降し始めていることを観察しました。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_TABLE_6.png 70%](https://lab-static.pingcap.com/images/2025/8/20/4b45d2214274ece8dabdb0816a2eab112c042c0f.png)

+ [ターミナル 2](ssh://monitor1-ssh#2) で、`tiup bench` ツールを使用してテーブル `test.tbl_ime_R2` をスキャンします。スキャンは継続的に行われるため、スキャンが終了するのを待たずにすぐに次の操作を実行してください。（テーブルのスキャンはおおよそ3~5分間続く予定です。）

  ```bash
  cat > table_scan_tbl_ime_R2.sql <<EOF
  SELECT sID, ID, txt FROM test.tbl_ime_R2 IGNORE INDEX (pcStateIndex, pcsID) WHERE ((pState = 's1') OR (pState = 's2') OR (pState = 's3')) OR ((pState = 's3' AND cState = 10) OR (pState = 's3' AND cState = 20)) AND NOT (sID = 200001 AND ID = 1097) AND NOT (sID = 0 AND ID = 0) LIMIT 50;
  EOF
  tiup bench rawsql run -H ${HOST_DB1_PRIVATE_IP} -P 4000 --count 100000 --threads 1 --query-files table_scan_tbl_ime_R2.sql
  ```

  ```output
  Starting component bench: /home/ec2-user/.tiup/components/bench/v1.12.0/tiup-bench rawsql run -H 10.90.2.164 -P 4000 --count 100000 --threads 1 --query-files table_scan_tbl_ime_R2.sql
  [Current] TABLE_SCAN_TBL_IME_R2: 0.00s
  [Current] TABLE_SCAN_TBL_IME_R2: 0.00s
  ...
  ```

+ 再度 [Grafana dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) に戻り`tidb-demo-TiKV-Details` の `In Memory Engine` タブで、`Region Cache Hit`、`Region Cache Hit Rate`、および `Region Cache Miss Reason` パネルを通じて、現在 `region2` の TiKV ノードが TiKV MVCC メモリエンジンを使用しており、`Region Cache Hit Rate` が `100%` に近いことがわかりました。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_TABLE_7.png 70%](https://lab-static.pingcap.com/images/2025/8/20/8377b214517b9c937a309c8e7e7e4b82c1ed7093.png)

+ `tidb-demo-TiKV-Details` の `Coprocessor Detail` タブでは、`Total Ops Details by CF (Table Scan)` パネルを通じて、現在 `region2` の TiKV ノードのコプロセッサにおいて、RocksDB の各 CF に対するテーブルのスキャン中に発生するさまざまなイベントの発生率を確認しました。例えば、`write-next` イベントは約 90K ops/m ～ 150K ops/m、`write-processed_keys` イベントは約 90K ops/m ～ 150K ops/m、`write-seek` イベントは約 450 ops/m の範囲です。`region1` の TiKV ノードで TiKV MVCC メモリエンジンを使用していなかった前回のクエリと比較して、関連イベントの発生率は大幅に低下しています。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_TABLE_8.png 70%](https://lab-static.pingcap.com/images/2025/8/20/d36cf2c3da511834019a24fc061701776e5ed39b.png)

+ `tidb-demo-TiKV-Details` の `gRPC` タブでは、`99% gRPC message duration` パネルを通じて、現在 `coprocessor` の 99% の実行遅延が約 743μs の範囲にあることがわかりました。これは、`region1` の TiKV ノードで TiKV MVCC メモリエンジンを使用していなかった前回のクエリと比較しても低下しています。また、`gRPC message count` パネルにおいて `coprocessor` の頻度が向上しています。以下の図のようになります（図例の `coprocessor` タブをクリックすると、より詳細に確認できます）：

  ![IME_PART3_TiKV_DETAIL_TABLE_9.png 70%](https://lab-static.pingcap.com/images/2025/8/20/5859487265ca34e1409ed6eea1b1e3d2cfab982b.png)

+ [ターミナル 2](ssh://monitor1-ssh#2) で、テーブル `test.tbl_ime_R2` のスキャンが終了するのを待つか、**CTRL-C**を押してスキャンを終了します。

  ```output
  ...
  [Current] INDEX_SCAN_TBL_IME_R2: 0.00s
  [Current] INDEX_SCAN_TBL_IME_R2: 0.00s
  Finished
  [Summary] INDEX_SCAN_TBL_IME_R2: 0.00s
  ```

+ 再度 [Grafana dashboard](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) に戻り、`tidb-demo-TiKV-Details` の `Coprocessor Detail` タブで `Total Ops Details by CF (Table Scan)` パネルにおいて関連イベントの発生率が下降し始めていることを観察し、2 回のクエリにおける RocksDB のスキャン状況を比較することができます。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_TABLE_10.png 70%](https://lab-static.pingcap.com/images/2025/8/20/24e71cc077ee387f4b8c980b398a1d8f1257f541.png)

+ `tidb-demo-TiKV-Details` の `gRPC` タブでは、`99% gRPC message duration` において `coprocessor` の実行に関する 99% の実行遅延が下降し始めていることを観察し、2 回のクエリの 99% の `coprocessor` 実行遅延状況を比較することができます。以下の図のようになります：

  ![IME_PART3_TiKV_DETAIL_TABLE_11.png 70%](https://lab-static.pingcap.com/images/2025/8/20/e0de9ea57d7ae9cd97c65f6fd545ccfd57fb9989.png)

### 手順 6. データのクリーンアップ

+ [ターミナル 1](ssh://monitor1-ssh#1) で、TiDBサーバーインスタンスに接続します。

  ```bash
  mysql -h ${HOST_DB1_PRIVATE_IP} --port 4000 -u root
  ```

  ```output
  mysql> 
  ```

+ [ターミナル 1](ssh://monitor1-ssh#1) で、 本モジュールで使用されているすべてのデータをクリーンアップします。

  ```sql
  DROP TABLE IF EXISTS test.tbl_ime_R1;
  DROP TABLE IF EXISTS test.tbl_ime_R2;

  DROP SEQUENCE IF EXISTS test.seq_ime_R1;
  DROP SEQUENCE IF EXISTS test.seq_ime_R2;

  EXIT
  ```

  ```output
  mysql> DROP TABLE IF EXISTS test.tbl_ime_R1;
  Query OK, 0 rows affected (0.51 sec)

  mysql> DROP TABLE IF EXISTS test.tbl_ime_R2;
  Query OK, 0 rows affected (0.52 sec)

  mysql> 
  mysql> DROP SEQUENCE IF EXISTS test.seq_ime_R1;
  Query OK, 0 rows affected (0.51 sec)

  mysql> DROP SEQUENCE IF EXISTS test.seq_ime_R2;
  Query OK, 0 rows affected (0.51 sec)

  mysql> 
  mysql> EXIT
  Bye
  ```

+ 本モジュールはここで終了します。