# 大量 DML 操作导致 OOM - 背景
+ 案例背景:
  + 无论是优化器选择 index scan 还是 table scan , TiDB 都倾向 TiKV coprocessor 请求读取大量的数据
  + 索引扫描范围过大
```
MySQL [db_stat]> explain delete from t_stat where imp_date<='20200202';
+---------------------+--------------+------+------------------------------------------------------+
| id                  | count        | task | operator info                                        |
+---------------------+--------------+------+------------------------------------------------------+
| TableReader_6       | 220895815.00 | root | data:Selection_5                                     |
| └─Selection_5       | 220895815.00 | cop  | le(db_stat.t_stat.imp_date, "20200202")              |
|   └─TableScan_4     | 220895815.00 | cop  | table:t_stat, range:[-inf,+inf], keep order:false    |
+---------------------+--------------+------+------------------------------------------------------+
3 rows in set (0.00 sec)
MySQL [db_stat]> select count(*)  from t_stat where imp_date<='20200202';
+-----------+
| count(*)  |
+-----------+
| 184340473 |
+-----------+
1 row in set (17.88 sec)
```
-------------------------------------------------------------
```
MySQL [db_stat]> explain delete from t_stat where imp_date<='20200202';
+---------------------+--------------+------+------------------------------------------------------+
| id                  | count        | task | operator info                                        |
+---------------------+--------------+------+------------------------------------------------------+
| TableReader_6       | 220895815.00 | root | data:Selection_5                                     |
| └─Selection_5       | 220895815.00 | cop  | le(db_stat.t_stat.imp_date, "20200202")              |
|   └─TableScan_4     | 220895815.00 | cop  | table:t_stat, range:[-inf,+inf], keep order:false    |
+---------------------+--------------+------+------------------------------------------------------+
3 rows in set (0.00 sec)
MySQL [db_stat]> select count(*)  from t_stat where imp_date<='20200202';
+-----------+
| count(*)  |
+-----------+
| 184340473 |
+-----------+
1 row in set (17.88 sec)
```

当我们有大批量的数据需要清理的时候，可能会出发 too large transaction 异常，也有可能会由于 TiDB 节点内存不足导致 OOM。在这个案例中，imp_date 字段上虽然有索引，但是由于索引的扫描范围过大，无论是优化器选择 index scan 还是 table scan，TiDB 都倾向 TiKV coprocessor 请求读取大量的数据。

对于 TiKV 节点的大量读数据请求，会有两方面的影响：
- TiKV 节点的 Coprocessor CPU 使用率飙升，CPU 资源被打满，从而导致集群的 duration 升高
- 数据删除时，会加载到内存中，打满 TiDB 的内存资源，从而导致 OOM