MySQL架构优化——MySQL集群

gI正在开发一个具有以下结构的web应用程序：我们有“客户”，每个客户都有自己的“用户”。 每个客户（及其用户和其他数据）都与其他客户完全分离，他们之间没有共享数据。
此外，每个“客户”都有一个不同的子网站，来自该子网站的所有查询（由他或他的用户）都将始终指向一个customer.id

数据库的构建方式如下：

CREATE TABLE `customer` ( 
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT 
) ENGINE=InnoDB; 

CREATE TABLE `user` ( 
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
  `customerID` int(11) unsigned 
) ENGINE=InnoDB; 

CREATE TABLE `blogPost` ( 
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
  `userID` int(11) unsigned 
) ENGINE=InnoDB; 

我有许多像“blogPost”这样的表，它们通过用户连接到客户

一个常见的查询应该是这样的：

SELECT *  
FROM `blogPost` bp 
INNER JOIN `user` u 
ON bp.userID=u.id 
WHERE u.customerID = 324

值得注意的是，这些连接非常昂贵，而且确实不必要，因为我们进入子网站后，只对连接到特定客户的数据感兴趣

所以问题是如何改进数据库？我对这个主题读得越多，我就越困惑-
NDB（MySQL群集）存储引擎是未来的发展方向吗？
是否最好创建多个不同的数据库-每个客户一个？ 可能会在

blogPost

中添加一个冗余的

customerID

字段？

---

还有别的想法吗？MongoDB

首先让我们来清理NDB引擎，MySQL Cluster/NDB不是解决这个问题的方法，它不仅没有提供任何对您的情况有帮助的东西，而且实际上使它更加复杂。您不仅需要大量的资源和至少3台数据库服务器来运行NDB，而且NDB中的连接等功能仍然不太好——只是不要这样做

连接表并没有什么错，RDBMS的设计就是为了有效地完成这项工作。如果您加入外键索引，这将是既快速又高效的。这里您要做的是绝大多数web数据库每天都要处理的事情，它们中的大多数将信息连接在一起

您可以为每个客户提供一个数据库，但请相信我，这将极大地增加您的数据库管理工作，如果您真的不必因为业务等原因而走这条路，请不要走这条路。当模式发生变化时，当客户x出现性能问题而客户y没有时，这将是一场噩梦——你最终会给自己带来很多工作

所以问题是如何改进数据库

是的，连接很贵。特别是如果（正如CREATETABLE语句所暗示的）您没有索引。如果确实如此，则必须添加索引，至少在主键和外键上添加索引。（我还注意到，根据你的设计，你没有为博客帖子存储任何内容？真的吗

常见的查询可能是

真的吗？如果您的查询没有实现任何类型的过滤，那么您的应用程序就会出现严重问题。如果过滤是以分页方式实现的，并且数据很少被删除/更新，那么每外键序列号将比全局自动递增ID更有效

是否最好创建多个不同的数据库

绝对不是

当然，如果您的物理设备将I/O分布在不同的磁盘上，将提高I/O性能（假设您的DBMS配置正确，并且热数据集太大，无法装入内存）在这种情况下，您应该考虑将索引和数据文件交织在不同的磁盘上，和/或使用MySQL的内置支持来跨文件系统进行分页。 可能会在blogPost中添加一个冗余的customerID字段

也许吧

集群对于可用性和性能来说都是一个很好的主意，但它在设置和保持运行所需的技能和时间方面带来了开销。现在当然不应该看NDB了-在您已经用尽了调整单个实例的范围之后，请尝试同步和异步REPL阳离子

---

从添加索引开始，然后调整DBMS配置，然后尝试将customerID添加到BlogPost中，然后看看文件是如何在存储中分布的（这看起来像是SSD的一个很好的用例）。

MySQL群集无法解决这个问题，我想知道你是如何想到这个主意的？有一个“选择*”，表似乎非常基本，但关于选择特定列而不是所有内容？表有更多字段-我只写主键和外键…通常我只选择相关列-此查询只是一个示例，显示我试图摆脱的连接…我认为MySQL cluster创建了行簇-因此每个customer和相关数据可以在他自己的集群中…也许这不是真的-我正在寻找任何解决方案，不限于MySQL集群谢谢..我明白你的意思，但我担心诸如message（id，from_user，to_user，content）之类的表。假设我只有1000个客户，每个客户平均有200个用户-我会将每个用户的消息量限制为100。因此，我们有一个包含1000*200*100=20000000条记录的表。难道没有更具可扩展性的方法吗？[不同客户的用户不能相互发送消息]@gilads当您引入可伸缩性时，这个问题开始扩大-您可以做一些事情，例如对数据库进行分区/分片，制定归档策略等。甚至可能是一个不涉及RDBMS-XML/无SQL etc1的解决方案。我不熟悉“查询过滤”的概念-你的意思是什么？2.你谈到了采用当前的体系结构并使用不同的方法对其进行优化-这很好，也很有帮助，但我担心诸如message（id，from_user，to_user，content）之类的表.让我们假设我只有1000个客户，每个客户平均有200个用户-我将每个用户的消息量限制为100。因此，我们有一个包含1000*200*100=20000000条记录的表..难道没有更具可扩展性的方法吗？[不同用户]