MySQL分片方法？

切分MySQL表的最佳方法是什么。 我能想到的方法是：

应用程序级分片

MySQL代理层的分片

用于分片的中央查找服务器

你知道这方面有什么有趣的项目或工具吗

应用程序级分片：dbShards是我所知道的唯一一款实现“应用程序感知分片”的产品。网站上有几篇好文章。根据定义，支持应用程序的分片将更加高效。如果应用程序准确地知道事务处理的位置，而不必查找事务或通过代理重定向事务，那么它本身的速度会更快。当有人在研究切分时，速度往往是最主要的考虑因素之一，如果不是唯一的考虑因素的话

有些人用代理人“切分”，但在我看来，这违背了切分的目的。您只是在使用另一台服务器来告诉事务在何处查找数据或在何处存储数据。通过应用程序感知切分，您的应用程序知道自己要去哪里。效率更高

这实际上与#2相同

---

切分MySQL表的最佳方法是不要这样做，除非这样做是完全不可避免的

在编写应用程序时，您通常希望以最大化速度、开发人员速度的方式来编写应用程序。您只在必要时优化延迟（直到答案准备就绪的时间）或吞吐量（每个时间单位的答案数）

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

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

分片的读取情况是，数据的大小太大，以至于它的工作集不再适合内存，并且数据读取开始命中磁盘，而不是大部分时间由内存提供

只有当你有来切分时，你才能这样做

---

在你分享的那一刻，你正在以多种方式为此付出代价：

大部分SQL不再是声明性的

通常，在SQL中，您告诉数据库您需要什么数据，并将其留给优化器将该规范转换为数据访问程序。这是一件好事，因为它很灵活，而且编写这些数据访问程序是一项无聊的工作，会影响速度

在分片环境中，您可能正在将节点a上的表与节点B上的数据连接起来，或者在节点a和B上有一个比节点大的表，并且正在将来自该表的数据与节点B和C上的数据连接起来。您正在开始手动编写基于应用程序端哈希的连接解析，以便解决该问题（或者您正在改造MySQL集群），这意味着您将得到大量不再是声明性的SQL，而是以过程方式表达SQL功能（例如，在循环中使用SELECT语句）

您正在承受大量的网络延迟

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

在分片环境中，查询可以通过跨网络运行对多个节点的键值访问来解决（最好是成批的键值访问，而不是每次往返的单个键值查找），或者通过将

WHERE

子句的一部分向前推到可以应用它们的节点（称为“条件下推”），或两者兼而有之

但即使在最好的情况下，这也会涉及更多的网络往返，而这是一种局部情况，而且更为复杂。特别是因为MySQL优化器对网络延迟一无所知（好的，MySQL集群在这方面正在慢慢进步，但对于集群之外的香草MySQL来说，这仍然是正确的）

您正在失去SQL的很多表达能力

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

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

当相同类型的数据驻留在多个节点上时（例如，节点A、B和C上的用户数据），通常需要针对所有这些节点解决水平查询（“查找90天或更长时间未登录的所有用户帐户”）。数据访问时间随节点数线性增长，除非可以并行询问多个节点，并在它们进入时聚合结果（“Map Reduce”）

这样做的先决条件是一个异步通信API，MySQL没有这样一个良好的工作状态。另一个选择是在子进程中进行大量的分叉和连接，这是在一个季节通行证上访问吮吸世界

---

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

如果您想要自动切分（例如，通过散列主键来确定哪一行进入哪个节点），或者您想要以手动方式进行功能拆分（“与xyz用户故事相关的表转到该主机，而与abc和def相关的表转到该主机”）

功能性分片的优点是，如果操作正确，大多数开发人员在大多数情况下都看不到它，因为与他们的用户故事相关的所有表都将在本地可用。这使他们能够尽可能长时间地从声明性SQL中受益，并且

    CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATETIME) PARTITION BY HASH ( YEAR(col3) );