# Dml Operations Cause Oom
+ Case background:
  + Whether the optimizer chooses an index scan or a table scan, TiDB tends to read large amounts of data from the TiKV coprocessor
  + Index scan range is too large
```
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)
```

When we have a large amount of data that needs to be cleaned up, we may start a too large transaction exception, or OOM may be caused by insufficient memory on the TiDB node. In this case, although there is an index on the imp_date field, TiDB tends to request the TiKV coprocessor to read a large amount of data because the index scan range is too large, whether the optimizer chooses index scan or table scan.

There are two implications for large read data request TiKV nodes:
- Coprocessor CPU usage of TiKV nodes spikes and CPU resources are full, resulting in high cluster duration
- When data is deleted, it is loaded into memory, filling up the memory resources of TiDB, resulting in OOM