MySQL分片方法？?mysql

除非无法避免，否则最好的方法是使MySQL表不这样做。

在编写应用程序时，通常希望以最大化速度和开发者速度的方式进行编写。仅在必要时才优化延迟（直到准备好答案的时间）或吞吐量（每个时间单位的答案数）。

仅当所有这些分区的总和不再适合单个数据库服务器实例时，才对分区进行分区，然后将其分配给不同的主机（=分片）-原因是写入或读取。

写的情况是a）写入频率使该服务器磁盘永久过载，或者b）正在进行过多的写操作，因此复制永久滞后于此复制层次结构中。

分片的读取情况是数据的大小太大，以致其工作集不再适合内存，并且数据读取开始击中磁盘，而不是大部分时间从内存中获取数据。

仅在必须分片时才这样做。

分片后，您会以多种方式为此付费：

您的大多数SQL不再是声明性的。

通常，在SQL中，您是在告诉数据库所需的数据，然后将其留给优化器以将其转换为数据访问程序。这是一件好事，因为它很灵活，而且因为编写这些数据访问程序是无聊的工作，会损害速度。

在分片环境中，您可能正在将节点A上的表与节点B上的数据连接起来，或者在节点A和B上具有比节点大的表，并将来自该表的数据与节点B和C上的数据连接起来。为了解决该问题，您开始手动编写基于应用程序端的基于散列的连接解析（或者您正在重塑MySQL集群），这意味着您最终将获得许多不再声明性的SQL，而是以过程方式表达SQL功能的SQL。 （例如，您在循环中使用SELECT语句）。

您将招致很多网络延迟。

通常，SQL查询可以在本地解决，优化器会知道与本地磁盘访问相关的成本，并以使成本最小化的方式来解析查询。

在分片环境中，可以通过以下方式解决查询：在网络上对多个节点运行键值访问（希望通过批量键访问，而不是每次往返都进行单个键查找），或者通过将WHERE子句的一部分向前推到它们可以使用的节点上或同时应用（称为“条件下推”）。

但是，即使在最好的情况下，这也要涉及比本地情况更多的网络往返，并且更加复杂。尤其是由于MySQL优化器对网络延迟一无所知（好吧，MySQL群集正在慢慢变得更好，但是对于群集外的原始MySQL来说仍然如此）。

您正在失去大量的SQL表达能力。

好的，这可能不太重要，但是外键约束和其他SQL数据完整性机制无法跨越多个分片。

MySQL没有允许正常工作的异步查询的API。

当相同类型的数据驻留在多个节点上（例如，节点A，B和C上的用户数据）时，通常需要针对所有这些节点解决横向查询（“查找90天未登录的所有用户帐户”或者更多”）。数据访问时间随节点数线性增长，除非可以并行请求多个节点并且结果随输入而汇总（“ Map-Reduce”）。

前提条件是异步通信API，对于良好的MySQL而言，它不存在。另一种选择是在子过程中进行大量分叉和建立联系，这正在访问整个季节过程。

一旦开始分片，数据结构和网络拓扑将成为您应用程序的性能指标。为了合理地执行性能，您的应用程序需要了解这些内容，这意味着实际上只有应用程序级分片才有意义。

问题是更多的，如果您想自动分片（例如，通过对主键进行散列来确定哪一行进入哪个节点），或者您想以手动方式进行功能拆分（“与xyz用户案例相关的表将转到此主，而与abc和def相关的表将转到该主”。

功能分片的优势在于，如果操作正确，大多数时候大多数开发人员都看不到它，因为与用户故事相关的所有表都可以在本地使用。这使他们仍然可以尽可能长时间地受益于声明式SQL，并且由于跨网络传输的次数保持最小，因此还可以减少网络延迟。

功能分片的缺点是它不允许任何单个表都大于一个实例，并且需要设计人员的手动注意。

功能性分片的优点是，相对容易地对现有代码库进行了很多更改，但变化不算太大。在过去的几年中，http：//Booking.com做了多次，对他们来说效果很好。

说了这么多，看着你的问题，我相信你在问错问题，或者我完全误解了你的问题陈述。来源：stack overflow