1000的表或多个mysql实例？

Question

我继承了一个公司应用程序，每个“对象”使用58个表，应用程序可以有N个对象。我们正在考虑为一个应用程序安装75到100个对象，这是4300-5000个表。

我们想要弄清楚的是，我们是想要使用一个数据库，并为每个对象添加表名，或者每个对象使用一个数据库（应用程序支持两者）。唯一的区别是每次安装应用程序时，如果我们要对每个数据库执行，我们需要在不同端口上使用其他mysql实例。

有没有人做过类似的事情？是否有任何问题（管理层之外）在数据库中有4000多个表？

修改的

感谢您的更新。至于一堆评论

1）公司付出的代价很高......我不愿意接受这份工作。我希望只写出很好的代码将$$放入我的银行账户

2）我们的客户对产品感到满意。我们已经考虑重新编写它，但除了成本之外，我们还会错过这个市场。虽然结构不好，但应用程序比大多数客户端都要好。

3）对象不是最好的术语......它不像对象/类，而是应用程序内的对象。我想我可以说代替。

Answer 1

如果你重复58个表一百次，我会建议规范化规则被践踏。您的公司不太可能会重新审视此产品的架构设计，但我会根据您提供的信息推荐它。

不要通过分发数据库使情况变得更糟。延迟如何帮助？

Answer 2

MySql将每个表存储为一个文件，除了您的操作系统和硬盘驱动器之外没有任何限制。但是，有一个原因并不常见 - 拥有数千个表几乎肯定是错误的，你的数据库模式可能非常需要重新设计。

Answer 3

奇怪的是，我已经看过这种应用了，我能告诉你的最好的事情就是重写应用程序。停止销售应用程序，直到设计可以被重新考虑为每个对象不涉及58个表。

Answer 4

我在一家公司工作，实现了类似于你所说的东西。我们使用的是名为RAMCO的产品，它以任何一种方式实现，我们选择将所有表保存在一个数据库中。我们之所以选择此方法有多种原因（包括更轻松的管理，备份，复制和群集）。有趣的是，虽然你有这样一个脱节的数据模型，你输入的实际数据量不会超过你放入不同模型的数据。因此，我们的备份大约12GB未压缩。至于引擎，它可以很好地处理那么多表。

话虽如此，我同意其他所有答案到目前为止您的公司应该重新考虑他们的数据架构（或者如果我是你，我会重新思考我是否真的想为一家能够实施某些事情的公司工作像那样）。在我的情况下，comapny拒绝放弃产品，所以我找到了其他工作。

Answer 5

很难说没有看到实际的架构（以及为什么在地球上一个对象可能需要58个表），但是如果你需要加入这些表，你需要将它们保存在一个数据库中。

在一个数据库中拥有多个MyISAM表意味着一次性使用它们意味着需要拥有大型table_cache。

Answer 6

如果您可以保证表的数量不会无限制地增加，那么拥有相当多的表是没有问题的。

真正的主要问题是表缓存（实际上应该大于表的总数，除非你想要性能很糟糕）以及引擎和操作系统的限制。

我们经常使用MyISAM，每个服务器有2000多个表，如果您已经调整并测试它以使用该卷，则没有特定问题。

确保使用预期数量的表进行性能测试。打开桌子可能很昂贵，所以请确保不要超过必要的时间。

当你关闭一张桌子时，某些引擎（MyISAM）会抛出一些缓存数据（仅限关键块），如果你定期关闭它们，这非常糟糕。

根据选项的不同，您的引擎每个打开的表可能需要一个或多个文件描述符。通常（在Linux上无论如何）mysql应该使用ulimit正确调整最大数量，但在某些情况下它可能不会。

在某些时候，你可能会遇到一个操作系统范围的限制（我认为在某些Linux版本上默认为32k），并且必须通过sysctl或其他一些调整来增加它。