为什么不分区？

什么时候不希望对数据库进行分区？（考虑MySQL分区）

就我而言

• 我将从几百万行开始，应该从那里开始。
• 字符字段上的主键用作最频繁的查询约束（并且查找也很频繁-至少每秒几次）。
• 主键将被散列为分区键
• 将对上述频繁查询中提取的每一行进行更新
• 频率较低的查询（针对日期列或其他查询）将需要访问所有分区

即使到最后一点，查找也不是并行运行的，因此在所有情况下，这都是胜利吗？分区的不利之处是什么？为什么至少在查看百万条记录时，每个人都默认不使用它？

更新-我选择了zgguy的答案，但请注意，我在自己的研究结果中添加了自己的答案，其中包括指向对我非常有用的类似问题的非常好的答案的链接。

没有解决性能问题的灵丹妙药，分区也不是其中之一。

每个分区本质上都是一个表。因此，以允许数据库仅在一个分区中查找行的方式编写的查询会变得更快。对于需要扫描整个大表的查询而言，差异可能很大，但可以将自身限制为仅扫描分区表中的一个分区。对于唯一的键查找，差异要小得多。

但是，以要求数据库访问所有或大部分表（索引）分区的方式使用索引查找的查询的运行速度将大大降低。

并行执行本身就是一个主题。如果您隔夜运行大量批处理，并且让整个计算机完成一项工作，那么并行化将是一件好事。但是，在OLTP系统中，数据库不断为来自多个并发用户的查询提供服务，您不希望一个用户占用所有资源。

此处的答案写得很好，并且使参数类似于zgguy的答案，分区不会给您带来很多好处（如果有的话），对单机情形很有帮助，在这种情形下，最频繁的查找是基于主键或类似的操作（因为索引查询应该一样快）。

实际上，一个通用的建议线程似乎是分区的主要原因是切线的，并且主要与管理有关：例如，如果您需要经常清除旧记录，则基于日期对数据进行隔离。尽管已指出，如果您的数据使得大多数所有查询仅命中最近添加的记录，这也可以使您的查询性能受益。

我还提到MySQL永远不会并行执行任何操作（很高兴看到一些链接或对此进行更多解释）。

尚未见任何人谈论写作活动是否增加了不同的考虑因素。

首先想到的是分区修剪；如果那不是您的查询可以使用的东西。

您是否需要从表中清除大量数据，因为分区将帮助您。虽然年代久远，但是彼得的这篇文章没有什么要考虑的。

人们可以想到的另一件事是简单表的易用性……分区需要额外的工作和维护。