我知道，数据库设计真的很糟糕，但是在这里，我有某种论坛平台（基于 PunBB），并且对于每个论坛，我都生成了一组新的表。真是个坏主意。
时间过去了，现在我有超过 100,000 个表（SHOW TABLES; SELECT FOUND_ROWS();- 112965 rows in set (1.21 sec)）。性能非常好，因为这些表完成了索引的工作，并且当您直接引用一个表时，它的速度非常快。
现在的问题是我正在尝试备份所有内容并移动到另一台服务器。当然，这需要永远。我推出了一个mysqldump：
mysqldump --max_allowed_packet=500M --force --opt -u root -pXXXX a > fullbackup.sql
而且还在处理中，12小时多一点！备份的大小已经是 546 Mb，而 Mysql 仍然可以正常工作。
我尝试直接复制 Mysql 文件，但遇到了很多表已损坏的问题。
有什么想法可以加快速度吗？
如果您使用的是 AWS RDS，请拍摄快照。
如果不是，请使用其他一些基于快照的工具。Percona 有一个http://www.percona.com/software/percona-xtrabackup/。使用mysqldump备份大型数据库速度极慢
如果您的源数据库已经损坏，那是一个独立的问题。
如果您正在复制数据库并且副本已损坏，那是因为您正在执行“热复制”，这意味着您无法在没有特殊“快照工具”的情况下复制数据库。甚至文件系统也有这样的工具。您需要一组一致的文件。
在我的上一份工作中，我们使用超过 160,000 个表运行 MySQL 实例。
有了这么多表，我们必须禁用innodb_file_per_table所有表并将其存储在中央表空间文件ibdata1中。如果我们不这样做，服务器将无法有效运行，因为它有太多打开的文件。这在 MySQL 8.0 中应该更容易，但是在我们使用的旧版本的 MySQL 中，数据字典无法扩展到这么多表。
为了进行备份，我们使用了 Percona XtraBackup。这是一个开源工具，其工作方式与 MySQL Enterprise Backup 非常相似。它执行数据目录的物理备份，但它不会因直接复制文件而导致文件损坏的风险。Percona XtraBackup 通过复制文件来工作，但也不断复制 InnoDB 事务日志，因此可以恢复文件丢失的位。它非常可靠。
使用 Percona XtraBackup 备份数据库要快一些，但在恢复备份时会带来更大的好处。从 mysqldump 恢复转储文件非常慢。恢复像 Percona XtraBackup 一样的物理备份可以尽快完成，您可以将备份文件复制到新的数据目录，然后启动 MySQL 服务器。
Percona 最近的一篇博客显示了不同之处：
https://www.percona.com/blog/2018/04/02/migrate-to-amazon-rds-with-percona-xtrabackup/
我推测，当您复制正在使用 InnoDB 的文件时，您的表已损坏。
它在这里的 MySQL 文档中说
物理备份工具包括 MySQL Enterprise Backup for InnoDB 或任何其他表的 mysqlbackup，或 MyISAM 表的文件系统级命令（如 cp、scp、tar、rsync）。
您可以使用 MySQL Enterprise Backup 执行快速、可靠的物理热备份（即在数据库运行时）。我相信它虽然安静，但价格昂贵。