我希望从以前在现实世界中使用过复杂 mysql 的人那里获得有关现实世界环境中 Web 应用程序示例 mysql 结构的反馈。
例子~
教育管理应用。 80,000 名用户。 每个用户都有他自己的数据库，其中包含以下表格 -消息 - 上传 -等级 -信息
以及其他功能的更多表格
我想知道的是，在这种情况下，任何信息都将不胜感激
-这个数据库模型有效吗？ （基本上像 80,000 个数据库）还是有更好的方法（我有这种 痒 的感觉）？ - 这需要什么样的专用服务器？ 80,000 个数据库，每个数据库包含 10-15 个表，其中包含大量表，所有 80,000 人每天访问该站点 20-30 次，持续 10-20 个会话
【问题讨论】：
标签： mysql sql database database-design multi-tenant
开始运行。
现在！
除了玩笑，不要那样做。不要为每个用户创建一个数据库。这是管理、维护和查询的地狱。如果您需要知道哪些用户昨天登录了怎么办？你会查询每个数据库吗？？
你需要的结构是一样的，只是数据量有变化。只需拥有一个数据库，看看它是如何运行的，然后进行优化/微调。
我不想提起这句话，但在你的情况下它完全适用：
Premature optimization 是万恶之源（Donald Knuth）
在你知道你的瓶颈在哪里之前，不要试图优化你的解决方案。
尽您所能为您的数据库建模。担心您的约束、PK、FK、索引。做你的database-design 作业。然后让您的数据和软件运行起来。只有这样，您才会看到它在哪里起作用以及在哪里受到伤害。此刻，你优化了。
只有在你知道敌人是谁时才攻击你的敌人。
【讨论】：
使用适当的存储引擎来支持该模型会很有效。大多数最近的 no-sql 数据存储（hadoop、bigtable、mongodb 等）都非常适合这种场景。
如果您考虑一下，用户数据是在孤岛中划分数据存储的绝佳方式（不同用户数据库之间的大多数交互不需要是事务性的，并且几乎没有写请求的交换）
基本上我认为 no-sql 不会为用户数据岛本身内部的数据关系带来任何好处，因此关系和非关系存储性能差异应该没那么重要
如上所述，传统的关系数据库（如 mysql）并非旨在进行大规模管理，因此在这方面您可能需要考虑使用不同的数据存储（或聘请 dba 摇滚明星）
【讨论】：
Adrian 和 Lurscher 都已经提供了很多细节。
在不知道有多少数据和架构的情况下，很难进入设计。从一开始就有 80K 活跃用户，即使他们每天访问数据数百次，负载似乎也不大。我有一种感觉，您可以使用 users 表为 OLTP 环境创建规范化模式，并从那里与其他表一起工作。同样，驱动设计的是需求。例如，用户查询的响应时间应该是多少？亚秒，一秒？
【讨论】：