什么对服务器的负担更大？数据库数量还是数据量？
我在工作中继承了一个网络应用程序。每次添加用户/帐户时，它都会创建新的 MySQL 数据库。每个数据库通常最大为 300mb，但不能超过。在 AWS RDS 上运行的 271 个数据库中，Web 应用程序像糖蜜一样运行。
每个数据库中有一个表保存着90%的数据，并且在所有数据库中保存着相同的数据。因此，我可以从此表中获取数据并将其放入单独的数据库中，并使所有帐户也连接到该数据库。这将大大缩小每个数据库的大小。
但是，我担心它不会加快服务器速度，因为上面的数据库太多了。我不是数据库管理员，如果我的思路没有意义，我提前道歉。但我非常愿意学习。
在这种情况下，我应该尝试缩小数据库的数量还是应该尝试缩小每个数据库的大小？缩小每个数据库的大小真的有帮助吗？
I have inherited a web application at work. It creates new a MySQL database every time an user/account is added. Each database usually goes up to 300mb but no more. At 271 databases running on AWS RDS the web application is running like molasses.
There is one table in each database that holds 90% of the data and it holds the same data in all databases. Therefore, I can take the data from this table and put in a separate database and have all the accounts connect to this database as well. This will shrink the size of each database considerably.
However, I worry that it will not speed up the server because there are simply too many databases on it. I am not DB admin and I apologize ahead of time if my train of thought does not make sense. But I am very willing to learn.
Under the circumstances, should I try to shrink the number of databases or should I try to shrink the size of each database? Would shrinking the size of each database really help?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我怀疑直接是数据库数量的问题。但这是糟糕设计的明显迹象，我敢打赌其他地方也存在问题。例如，许多优化可以在表内进行，但不能跨表进行。因此，如果您不断地操作相同类型但保存在不同表中的信息，那么速度将会非常慢。
I doubt the number of databases is the problem directly. But that's such an obvious sign of bad design that I bet there are issues elsewhere. For example, many optimizations are possible within a table but not across tables. So if you're constantly manipulating information of the same type but held in different tables, it's going to be absurdly slow.
您应该（认真地）考虑将数据库的数量减少到一个。
每个用户一个数据库的概念是更......有趣......的概念之一我听说 - Pax 在那里表现出了异常的机智:-)
由于缺乏将不同用户彼此分开的某些立法要求，所以确实没有正当理由这样做。特别是如果您希望数据库能够扩展。
300M 乘以 300 个帐户大约为 90G，这仍然是一个相对较小的数据库。
正如您所说，很多信息都是重复的，因此当您合并时，它们不会到达任何接近的位置。如果这 300M 中的 90% 是共享的，那么您最终会得到类似 30M 乘以 300 个帐户加上 270M 共享的大小，或低于 10G。
我非常确定我们的一些配置表比这个大:-)
You should (seriously) look into reducing the number of database to one.
The concept of a single database per user is one of the more ... interesting ... ones I've heard - that's Pax showing an unusual amount of tact there :-)
Short of certain legislative requirements to separate different users from each other, there is really no valid reason to do this. Especially if you ever expect your database to scale.
300M times 300 accounts is about 90G and that's still a relatively small database in the scheme of things.
As you've stated, a lot of that information is duplicated so it won't get anywhere near that when you combine. If 90% of that 300M is shared, you'll end up with something like 30M multiplied by 300 accounts plus 270M shared, or under 10G.
I'm pretty certain some of our configuration tables are bigger than that :-)