mysql“删除数据库”需要时间——为什么？答案

【问题标题】：mysql "drop database" takes time -- why?mysql“删除数据库”需要时间——为什么？
【发布时间】：2010-09-14 02:01:44
【问题描述】：

mysql5.0 带有一对数据库“A”和“B”，都带有大型 innodb 表。 “删除数据库 A；”冻结数据库“B”几分钟。那时什么都没有使用“A”，为什么要进行如此密集的操作？

加分：假设我们使用“A”，将数据上传到“B”，然后切换到使用“B”，我们怎样才能更快地做到这一点？删除数据库并不是人们通常必须一直做的事情，所以这有点离谱。

【问题讨论】：

【解决方案1】：

默认情况下，给定 mysql 服务器安装中的所有 innodb 数据库都使用相同的数据文件物理池，因此可以想象“删除数据库 A”可能会影响数据库 B。由于“删除数据库”可能涉及大量的 innodb 重组数据文件，可以想象它是一个阻塞操作，要么是因为操作的强度，要么是设计的。

但是，我认为您可以让每个数据库使用不同的物理文件，尽管我自己没有尝试过，所以您必须自己弄清楚具体细节。如果做不到这一点，那么您可能需要在同一台机器上并排使用两个不同的 mysql 安装，这是完全可行的。

【讨论】：

【解决方案2】：

跟随斯卡夫曼：

更改您的 my.cnf（并重新启动 MySQL）以包括：

innodb_file_per_table = 1

这将为您的数据库提供专用文件存储并将其从共享池中取出。然后它可以让您做一些有趣的事情，例如将表/索引放在不同的物理磁盘上，以进一步拆分 I/O 并提高性能。

请注意，这不会更改现有表；您必须努力将它们放入自己的文件中 (http://capttofu.livejournal.com/11791.html)。

【讨论】：

我认为您夸大了使用 innodb_file_per_table = 1 拆分 I/O 的有用性 - RAID 是更好的选择。原因：InnoDB 不支持名为 DATA DIRECTORY 的 CREATE TABLE 选项。我想将单个表移动到另一个分区，我必须使用符号链接回到原始位置。一旦您运行 ALTER TABLE 命令，符号链接就会被破坏，并且表会移回原始位置。
我很惊讶这个单一选项会产生如此巨大的差异。你是一个救生员！

【解决方案3】：

所以我不确定Matt Rogish's answer 是否会 100% 提供帮助。

问题是 MySQL* 在打开和关闭表周围有一个互斥锁（互斥锁），所以这基本上意味着如果一个表正在关闭/删除的过程中，没有其他可以打开表格。

一个极好的减少影响的策略是使用像 XFS 这样的文件系统。

解决方法很糟糕。您基本上必须在删除表中的所有数据之前蚕食它们（请参阅上面链接上的评论 #11）。

【讨论】：

所以你已经解释了锁定机制，这一切都是有道理的......但“为什么”仍然没有得到回答。在 Linux 中删除一堆文件不需要很长时间。所以我猜在引擎盖下有更复杂的事情发生。如果是这样，'为什么'它会这样做，而不是在几秒钟内简单地删除它的文件和'宾果游戏'......表都被删除了？
除了 fs 缓慢删除之外还有另一个原因 - 如果有一个非常大的缓冲池，可能会出现冻结，试图驱逐属于即将被删除的表的所有页面。这可能在 5.5/5.6 中通过“惰性”免费方法得到了改进。
以上链接失效，重定向到其他网站。