在 sybase-select 查询中对表进行分区答案

【问题标题】：Partitioning a table in sybase-select query在 sybase-select 查询中对表进行分区
【发布时间】：2014-08-25 13:52:13
【问题描述】：

我的主要担忧：

我有一个包含大量数据的现有表。它有一个聚集索引。我的 c++ 进程有一个包含许多键的列表，用于检查表中是否存在键，如果是，它将检查表中的行和新行是否相似。如果有更改，则表中的新行会更新。一般来说，变化会更少。但其庞大的数据在表中。 S 这意味着会有很多选择查询，但不会有很多更新查询。

我想要达到的目标：

我刚刚阅读了有关在 sybase here 中对表进行分区的内容。我只是想知道这对我有帮助吗，正如我在文章中看到的那样，它只提到了插入查询。但是如何提高我的选择查询性能。

谁能建议我在这种情况下应该寻找什么？

【问题讨论】：

您提到它将主要是选择语句，但分区是否有帮助还取决于您选择的内容。您是按日期或其他标识符选择数据子集，还是对整个数据集进行查询？如果没有关于您的表结构以及您选择的内容的更多详细信息，我们无法回答这个问题。
“海量数据”是什么意思？如果您在不进行分区的情况下进行了适当调整，您应该能够在数百万条记录上获得合理的性能。

【解决方案1】：

是的，只要您的查询基于定义的分区键，它就会提高您的查询（读取）性能。 Indexes can also be partitioned，按理说更小的索引意味着更快的读取性能。

例如，如果您有类似 select * from contacts where lastName = 'Smith' 的查询，并且您已根据 lastName 的第一个字母对表索引进行分区，那么服务器只需搜索一个分区“S”即可检索其结果。

请注意，如果您有很多不同的查询配置文件，对数据进行分区可能会很困难。不包括索引分区键（例如姓氏）的查询（例如 select * from staff where created > [some_date]）将必须命中每个索引分区才能检索其结果集。

没有人可以告诉您应该/不应该做什么，因为它是非常特定于应用程序的，您必须执行自己的分析。在干预分区之前，我的建议是确保你有正确的索引，它们被你的查询命中（即没有表扫描），并且你的服务器有适当的资源（即有足够的快速磁盘和 RAM），并且你已调整您的服务器缓存以适合您的查询。

【讨论】：