mysql - 使用 `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

我目前甚至没有使用该脚本，只是在 shell 中运行命令，结果相同。

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)。