什么时候不想对数据库进行分区?(思考MySQL 分区)
就我而言
- 我将从几百万行开始,它应该从那里增长。
- 用作最频繁查询限制的字符字段上的主键(并且查找很频繁 - 至少每秒几次)。
- 主键将被散列以用作分区键
- 将对上述频繁查询中提取的每一行进行更新
- 不太频繁的查找(针对日期列或其他)将需要命中所有分区
即使对于最后一点,查找不是并行运行的,所以在所有情况下,这是一个胜利吗?分区的缺点是什么?为什么不是每个人都默认使用它,至少当您查看一百万条以上记录时?
更新 - 我选择了 zgguy 的答案,但请注意,我在自己的研究结果中添加了自己的答案,包括指向对我非常有用的类似问题的非常好的答案的链接。
性能问题没有灵丹妙药,分区也不是。
每个分区本质上都是一个自己的表。因此,以允许数据库仅在一个分区中查找行的方式编写的查询会变得更快。对于需要扫描整个大表的查询来说,差异可能很大,但可能会限制自己只扫描分区表中的一个分区。对于唯一键查找,差异要小得多。
但是,以需要数据库访问所有或大部分表(索引)分区的方式使用索引查找的查询将运行得相当慢。
并行执行本身就是一个主题。如果您在夜间运行大批量,并让整台机器完成这项工作,那么它的并行化是一件好事。但是,在数据库不断为来自许多并发用户的查询提供服务的 OLTP 系统中,您不希望一个用户占用所有资源。
这里的答案写得很好,并且提出了类似于zgguy 的答案的论点,分区不会给你带来太多好处(如果有的话),它有利于最频繁的查找基于主键或类似的东西的单机场景(因为索引查找应该同样快)。
事实上,一个常见的建议似乎是分区的主要原因是切向的并且主要与管理相关:例如,如果您需要经常清除旧记录,请根据日期隔离您的数据。尽管有人指出,如果您的数据使得大多数查询只会命中最近添加的记录,这也可以提高您的查找性能。
我还看到提到 MySQL 从不并行执行任何操作(很高兴看到一些链接或更多解释)。
还没有看到有人谈论写作活动是否会增加不同的考虑因素。
首先想到的是分区修剪;如果这不是您的查询可以使用的东西。
您是否需要从表中清除大量数据,因为分区会帮助您。虽然很旧,但彼得的这篇文章没有什么要考虑的。
人们可以想到的另一件事是简单表的易用性……分区需要额外的工作和维护。