TRUNCATE TABLE 语句有时会挂起

Question

为什么TRUNCATE TABLE语句有时会挂起？出现此类问题的原因是什么？

我正在从 MySQL 迁移到 MariaDB。这个问题不会发生在 MySQL 上，只有发生在 MariaDB 上。

悬挂声明很简单：

TRUNCATE TABLE sampledb.datatable;

什么会导致这种情况发生，我该如何解决？

另一种观察是如果表有一些数据，可能是一两行，那么截断查询成功。否则表有很多数据，查询就挂了。

Answer 1

您在执行时遇到性能下降或停顿的原因TRUNCATE TABLE是此语句的一个已知问题。请参阅错误 #68184：Truncate table 导致 innodb 停顿。还为以前的版本打开了其他错误编号。

您可以使用：

CREATE TABLE log_table_new LIKE log_table;
RENAME TABLE log_table TO log_table_old, log_table_new TO log_table;
DROP TABLE log_table_old;

对于带有AUTO_INCREMENT值的表来说，这会变得很棘手：创建新表时AUTO_INCREMENT会立即使用工作表中的值。如果您不想使用相同的值，您可以：

ALTER TABLE log_table_new AUTO_INCREMENT=some high enough value;

Answer 2

您必须记住TRUNCATE TABLE是 DDL 而不是 DML。

与其弄清楚TRUNCATE TABLE的管道中的哪个位置卡住了，您可能只需要通过替换它来解决问题

TRUNCATE TABLE sampledb.datatable;

有了这个

CREATE TABLE sampledb.datatablenew LIKE sampledb.datatable;
ALTER TABLE sampledb.datatable RENAME sampledb.datatablezap;
ALTER TABLE sampledb.datatablenew RENAME sampledb.datatable;
DROP TABLE sampledb.datatablezap;

这可能只是使问题脱机（可能挂在 上DROP TABLE），但该表很快可用。DROP TABLE在 MySQL 5.5.23 中得到了改进。

我在过去的帖子中讨论过TRUNCATE TABLE

• Jul 09, 2012：什么会导致 TRUNCATE TABLE 花费很长时间？
• Jan 17, 2012; InnoDB“每表”文件大小的问题
• Sep 28, 2011:如何恢复文件被移动的 InnoDB 表

试一试 ！！！

Answer 3

InnoDB 中存在一个长期存在的错误，它会影响 MySQL ( #98869 ) 和 MariaDB ( MDEV-9459 )，这会导致长时间停顿，与缓冲池的大小成正比（通常每 32GB 缓冲池大约 1 秒，具体取决于服务器的 CPU 性能和内存带宽）。

此问题已在 MySQL 8.0.23 和 MariaDB 10.2.19 中修复。如果升级不是一个选项（我知道对于许多人来说，由于各种原因它可能不是一个令人满意的选项），有一些缓解措施和解决方法可以应用于 MySQL 和 MariaDB 的这些 DROP / TRUNCATE 停顿。

例如，在执行 DROP 之前，您从表中删除所有行并不会出现该错误。如果这在使用临时表的上下文中影响您，您可以将默认临时表引擎切换为 MyISAM（或在创建临时表时显式指定 MyISAM）。

披露：我写了引用的文章。