使用mysqldump缓慢写入数据库

Question

我试图从Azure Database for MySQL Server自动化所有数据库的mysql转储。数据库的当前大小：

mysql> SELECT table_schema "DB Name", Round(Sum(data_length + index_length)/1024/1024, 1) "DB Size in MB" 
     FROM information_schema.tables GROUP BY table_schema; 
+--------------------+---------------+ 
| DB Name   | DB Size in MB | 
+--------------------+---------------+ 
| db1    |   278.3 | 
| db2    |   51.8 | 
| information_schema |   0.2 | 
| mysql    |   8.9 | 
| performance_schema |   0.0 | 
| db3    |   43.3 | 
| sys    |   0.0 | 
+--------------------+---------------+ 
7 rows in set (31.80 sec) 

我有一个python脚本，在不同的虚拟机，调用mysqldump所有这些转储到一个文件中。但是，我遇到了db1的问题。它被转储到一个文件中，但速度很慢，在30分钟内低于〜4MB。然而，db2和db3几乎立即被转储，以秒为单位。

我已经尝试了所有的下列选项和组合，看是否写入速度的变化，但它并不：

--compress 
--lock-tables (true/false) 
--skip-lock-tables 
--max-allowed-packet (512M) 
--quick 
--single-transaction 
--opt 

我目前甚至没有使用脚本，只是运行中的命令一个外壳，结果相同。

mysqldump -h <host> -P <port> -u'<user>' -p'<password>' db1 > db1.sql 

db1有〜500个表格。

据我所知，它大于db2和db3但它不是那么多，我想知道是否有人知道这里可能是什么问题？

编辑

这些有用的答案，谷歌的研究后表明，该数据库是最有可能的罚款，我通过复制服务器上的db1数据库到测试数据库，然后逐个删除表一个运行测试减小尺寸。在大约50MB的时候，写入变得像其他数据库一样。这让我相信Azure中会有一些限制，因为数据库没问题，我们会和他们的支持团队一起讨论。我在Google上也发现了很多关于Azure数据库速度的帖子。

与此同时，我将脚本更改为忽略大型数据库。我们将尝试将数据库移动到由Azure提供的SQL Server或带有mysql服务器的简单虚拟机，以查看哪里可以获得更好的性能。

Answer 1

它可能在MySQL服务器端很慢，但似乎不太可能。您可以打开第二个shell窗口，连接到MySQL并使用SHOW PROCESSLIST或SHOW ENGINE INNODB STATUS来检查停滞的查询或锁定。

如果你的数据存储速度非常慢，它也有可能在将数据写入db1.sql时出现问题。但是4MB是30分钟。是荒谬的。确保你保存到你正在运行mysqldump的实例的本地存储。不要保存到远程存储。如果您正在编写转储的存储卷有其他繁重的I/O流量饱和，请注意，这可能会降低写入速度。

另一种测试缓慢数据写入的方法是尝试mysqldump ... > /dev/null，如果速度很快，那么这是一个很好的线索，表明缓慢是磁盘写入的错误。

最后，网络有可能导致缓慢。如果将转储文件保存到/ dev/null仍然很慢，我会怀疑网络。

---

在 https://serverfault.com/questions/233963/mysql-checking-permission-takes-a-long-time的回答表明，在“检查权限”慢度可能由具有在MySQL授权表（例如mysql.user）太多的数据而引起的。如果您拥有数千个用户凭证，则可能是原因。您可以尝试删除这些条目（之后运行FLUSH HOSTS）。

Answer 2

首先从数据库创建备份。在此之后，试试这个：

这个

mysqlcheck 

更多信息：mysqlcheck