【发布时间】：2015-04-21 06:45:20
【问题描述】：
我在 mysql 数据库中的一个大型 InnoDB 表上运行了一个不明智的 SELECT *。
所以大约 10 分钟后，我意识到了错误，使用 show processlist 找到了connectionid，并尝试使用 kill 命令终止连接和查询。然后我在同一张表上运行了另一个查询。
show processlist 显示原始选择已收到 Killed 标志，但卡在“发送数据”状态。后续查询正在等待锁定。这已经持续了几个小时。
现在我明白了，如果我的原始查询以任何方式修改了表，我所描述的将等待回滚。
但这是select；回滚选择甚至意味着什么？
所以我想知道是否有人可以告诉我我在等待什么，以及是否有任何方便的方法可以取消 select 查询。
【问题讨论】：
-
这里可能已经回答了问题：stackoverflow.com/questions/5043268/…
-
"如果表 email_data_test 是 InnoDB，那么很多 MVCC 数据正在写入 ib_logfiles，这可能还没有发生。"
-
感谢您的链接；这不是我在发布前搜索中找到的示例之一，但它与我找到的示例相似。他们在该线程中给出的解释为什么需要这么长时间才能杀死 - 除了为什么原始查询首先需要这么长时间 - 是“杀死查询只会导致 InnoDB 表 email_data_inno_stage 执行回滚。”这又回到了我最初的问题：为什么我需要回滚选择？
-
足够我编辑帖子的标题了。我希望这不会让任何人都难以追踪这个问题，但我在 meta-SO 上发现了一些帖子，似乎表明如果你想出一个更好的标题，那就值得去做。如果不合适，当然可以随意将其改回，或者您认为新标题更糟。 （具体来说，我认为这个更好，因为它将这个问题与已经在 SO 上回答过的数字区分开来，但是关于 INSERT / DELETES，回滚将是完全明智的。）
-
您不需要回滚 SELECT。仅仅因为终止写入查询通常会导致数据库回滚时的较长等待时间，并不意味着终止读取查询后的较长等待时间也是由于回滚。听起来好像还有其他事情发生。
标签： mysql sql innodb sql-optimization