MySQL:Slow Drop table命令

Question

我正在尝试使用

DROP TABLE IF EXISTS <myTableName>;

然而即使几个小时后它仍在运行.有关解决方法的任何建议吗？

Answer 1

我有同样的问题,它只是通过重新启动服务器解决:

sudo /etc/init.d/mysql stop
sudo /etc/init.d/mysql start

也许正在举行一些锁定并重新启动它.

Answer 2

更好的方法：

杀死所有以DROP操作方式进行的进程

假设您要table在数据库中删除表database

1）在并行会话中登录到mysql，最好以root用户身份登录。问题：

SHOW PROCESSLIST;

您将在db ^*上看到所有进程的列表：

+-------+-----------+-----------+----------+---------+------+---------------------------------+------------------------------+----------+
| Id    | User      | Host      | db       | Command | Time | State                           | Info                         | Progress |
+-------+-----------+-----------+----------+---------+------+---------------------------------+------------------------------+----------+
| 38239 | username  | 10.0.0.1  | database | Sleep   |  591 |                                 | NULL                         |    0.000 |
| 38240 | username  | 10.0.0.1  | database | Sleep   |  590 |                                 | NULL                         |    0.000 |
| 38245 | username  | 10.0.0.1  | database | Query   | 2636 | Waiting for table metadata lock | DROP TABLE IF EXISTS `table` |    0.000 |
| 38257 | username  | localhost | database | Query   |    0 | init                            | SHOW PROCESSLIST             |    0.000 |
+-------+-----------+-----------+----------+---------+------+-------+---------------------------------+----------------------+----------+

2）如果在DROP 之前有任何活动的进程，则应等待它们完成（或确定杀死它们）。

3）然后在等待一个之前杀死所有“休眠”的进程：

KILL 38239;
KILL 38240;

4）之后，被阻止的进程应继续执行DROP操作。

InnoDB中的一个已知问题是在DROP之前等待。

更新：还注意到非排他性更新（受影响记录的数量可能有所不同的更新）上的这种行为，例如：

# may update any number of customers, from 0 to all
UPDATE customers SET `active` = 'N' WHERE `last-payment-date` < 2018-01-01;

解决方案是完全一样的。

• _{所提供的表取自现实生活中的场景，为了安全和演示目的，对数据进行了混淆和略微编辑。}