mysql中杀进程占用时间长的内部原因

Question

我复制了一个大表的结构（顺便说一句，它是一个InnoDB表）

CREATE TABLE tempTbl LIKE realTbl

然后我更改了一个索引，并填充它以便我可以运行一些测试。使用以下方法填充它：

INSERT INTO  `tmpTbl` 
SELECT *
FROM `realTbl`

这花了太长时间，所以我想停止这个测试。¹

我在处于“发送数据”状态时终止了该进程：它现在已“终止”，并且仍处于“正在发送数据”状态。

我知道一些被杀死的进程需要恢复更改，因此与它们运行的时间相比可能需要（同样？）很长时间才能杀死，但我无法想象为什么现在会出现这种情况：需要清空整个表。

我很好奇正在发生的事情需要停止/终止这样一个简单的查询很长时间。给你一些数字：插入运行了一个小时或 3 个小时，现在杀死接近5 7。看起来它几乎DELETE每次都运行一次INSERT，并且删除比插入花费的时间更长？这甚至合乎逻辑吗？

（如果有人知道如何将我的测试服务器恢复原状也很好，因为它正在消耗一些资源，但目前这并不重要:)）

1）我还不知道为什么（它是一个大表，10M 行，但它应该需要那么长时间？），但这是另一件事/不是这个问题的一部分:)。可能是我的测试本可以更聪明或更快速，但这也不是现在的问题：D

Answer 1

kill 花费这么长时间的原因很可能是由于 innodb 事务发出的回滚。来自InnoDB 性能提示：

小心大量插入的大回滚：InnoDB 使用插入缓冲区来保存插入中的磁盘 I/O，但在相应的回滚中没有使用这种机制。磁盘绑定回滚的执行时间可能是相应插入的 30 倍。终止数据库进程无济于事，因为回滚在服务器启动时再次启动。

编辑： 在InnoDB的强制恢复方法可能是使用的你（很高兴你这样做是在测试环境下）

您可以终止 mysqld 进程并将 innodb_force_recovery 设置为 3 以在不回滚的情况下启动数据库，然后删除导致失控回滚的表。

下一次，每次插入一小部分数据。插入 1000 万行不应该花那么长时间，但可能有多种原因。在不了解您的环境的情况下，我无法就此提供建议。