MySQL使用命令kill进程后出现killed死锁问题

在zabbix监控时，会由于监控项庞大的原因，会导致history表超级大的场景产生

有一张4亿行的表，现在要对这张表进行删除3亿行，于是就会有如下的操作：
```SQL
delete from history limit 300000000;;
```
毫无疑问这是一个非常差的删除方式，便有人开始变更删除方式：
```SQL
delete from history  where clock < 1633017600;
```
运行一段时间后，发现批量删除的效率可能会更高，所以kill掉了上一条运行了一段时间的SQL，开始批量删除;
由于是大SQL，晚上点击运行想第二天早上来看结果的DBA就会遗憾的发现新执行的SQL被锁给挡了回来，并没有运行。
但是盲目的等待锁释放心里没底，所以我们可以通过下面的方式计算出这个锁什么时候能够释放.
### 场景
> 一个巨大的delete语句 执行一小时后kill ，
show processlist出现killed进程 ，

不要盲目重启！ 重启MySQL后进程消失但锁依然存在！
重启MySQL后进程消失但锁依然存在，因为回滚还要继续，这是MySQL对数据的保护机制
通过下列语句查询事务情况：
```SQL
mysql> SELECT * FROM information_schema.INNODB_TRX\G
*************************** 1. row ***************************
                    trx_id: 186960803
                 trx_state: ROLLING BACK
               trx_started: 2021-11-22 12:03:42
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 59814090
       trx_mysql_thread_id: 97030
                 trx_query: delete from history  where clock < 1633017600
       trx_operation_state: fetching rows
         trx_tables_in_use: 1
         trx_tables_locked: 1
          trx_lock_structs: 1657213
     trx_lock_memory_bytes: 201171152
           trx_rows_locked: 519993467
         trx_rows_modified: 58156838
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
1 row in set (0.04 sec)
mysql>
```
其中，`trx_rows_modified`: 代表锁影响的行数，当数值为0时，锁将会释放

### 查看表锁信息
```SQL
mysql> SELECT * FROM information_schema.INNODB_LOCKS;
Empty set (0.05 sec)

mysql> SELECT * FROM information_schema.INNODB_LOCK_waits;
Empty set (0.03 sec)
```

ERROR:
No query specified
mysql> desc information_schema.innodb_trx;
+----------------------------+---------------------+------+-----+---------------------+-------+
| Field                      | Type                | Null | Key | Default             | Extra |
+----------------------------+---------------------+------+-----+---------------------+-------+
| trx_id                     | varchar(18)         | NO   |     |                     |       | -- 事务ID
| trx_state                  | varchar(13)         | NO   |     |                     |       | -- 事务状态：
| trx_started                | datetime            | NO   |     | 0000-00-00 00:00:00 |       | -- 事务开始时间；
| trx_requested_lock_id      | varchar(81)         | YES  |     | NULL                |       | -- innodb_locks.lock_id
| trx_wait_started           | datetime            | YES  |     | NULL                |       | -- 事务开始等待的时间
| trx_weight                 | bigint(21) unsigned | NO   |     | 0                   |       | --
| trx_mysql_thread_id        | bigint(21) unsigned | NO   |     | 0                   |       | -- 事务线程ID 
| trx_query                  | varchar(1024)       | YES  |     | NULL                |       | -- 具体SQL语句
| trx_operation_state        | varchar(64)         | YES  |     | NULL                |       | -- 事务当前操作状态
| trx_tables_in_use          | bigint(21) unsigned | NO   |     | 0                   |       | -- 事务中有多少个表被使用
| trx_tables_locked          | bigint(21) unsigned | NO   |     | 0                   |       | -- 事务拥有多少个锁
| trx_lock_structs           | bigint(21) unsigned | NO   |     | 0                   |       | -- 
| trx_lock_memory_bytes      | bigint(21) unsigned | NO   |     | 0                   |       | -- 事务锁住的内存大小（B）
| trx_rows_locked            | bigint(21) unsigned | NO   |     | 0                   |       | -- 事务锁住的行数
| trx_rows_modified          | bigint(21) unsigned | NO   |     | 0                   |       | -- 事务更改的行数
| trx_concurrency_tickets    | bigint(21) unsigned | NO   |     | 0                   |       | -- 事务并发票数
| trx_isolation_level        | varchar(16)         | NO   |     |                     |       | -- 事务隔离级别
| trx_unique_checks          | int(1)              | NO   |     | 0                   |       | -- 是否唯一性检查
| trx_foreign_key_checks     | int(1)              | NO   |     | 0                   |       | -- 是否外键检查
| trx_last_foreign_key_error | varchar(256)        | YES  |     | NULL                |       | -- 最后的外键错误
| trx_adaptive_hash_latched  | int(1)              | NO   |     | 0                   |       | -- 
| trx_adaptive_hash_timeout  | bigint(21) unsigned | NO   |     | 0                   |       | -- 
| trx_is_read_only           | int(1)              | NO   |     | 0                   |       | -- 事务是否只读
| trx_autocommit_non_locking | int(1)              | NO   |     | 0                   |       | --
+----------------------------+---------------------+------+-----+---------------------+-------+
24 rows in set (0.01 sec)
```
### 结论
时间过长的update、delete等语句在kill之后会进行回滚操作，会锁表，经常有人更换不同方式对大数据进行修改删除，然而盲目的杀死正在长时间运行的进程后并不能马上对表进行新的操作，后果只能是等待之前的操作回滚结束，本想用更快的方式操作表结果得不偿失，所以还是建议选择好对表修改操作方式然后一次运行，不再修改。