与非分区表计算视图相比，SAP HANA分区表计算视图运行缓慢

我有一个很大的表，接近1GB，这个表的大小每周都在增长，它的总行数为1.9亿，我开始从HANA获得警报来分区这个表，所以我计划用Where子句中经常使用的列来分区这个表

我的HANA系统是具有8个节点的横向扩展系统

为了比较分区查询性能与这个未分区表的差异，我在这个未分区表的顶部创建了计算视图，并记录了查询性能

我使用哈希方法和服务器数量对该表进行分区，并记录查询性能。通过这种方式，我可以在服务器之间获得良好的数据分布。我创建了计算视图并记录了查询性能。 令我惊讶的是，我发现与分区表计算视图相比，我的未分区表计算视图查询的性能更好

这真是令人震惊。不知道为什么非分区表计算视图对分区表计算视图的响应更好

我有plan viz输出文件，但不确定将其附加到何处

---

让我知道为什么会这样。

好的，这不是一个可以正确回答的直截了当的问题。 但我能做的是列出一些可能会在这里发挥作用的因素：

• 非分区表需要对表结构进行一次访问，而分区版本要求每个分区至少进行一次访问
• 如果

  SELECT

  实际上没有提供可由用于分区的哈希函数计算的

  WHERE

  条件，则始终必须计算所有分区，并且不能进行分区修剪
• 散列分区不考虑关于数据的任何附加知识，这意味着相似的数据不会存储在一起。这对数据压缩有负面影响。此外，每个分区都需要自己的列值字典集，其中单个分区/非分区表每列只需要一个字典
• 您提到您正在使用扩展系统。如果表分区分布在不同的节点上，那么每个查询都将导致跨节点网络通信。这是一个额外的工作负载和等待时间，这在非分区表中是不存在的
• 在连接分区表时，如果不可能进行分区连接，则第一个表的每个分区都必须与第二个表的每个分区连接

为什么针对分区表的查询比针对非分区表的查询慢，还有其他/更多的潜在原因。所有这些都在本文中作了广泛的解释

---

作为一般性指导，只有在无法避免的情况下，以及在充分理解查询的访问模式时，才应该对表进行分区。这显然不是一个只需“打开”就可以正常工作的功能。

分区是一种很好的方法，可以将热数据和冷数据分开，并使表中经常使用的数据的大小更小。此外，如果数据位于不同的磁盘上，则可以通过处理并行读取来增加磁盘IO。也许读取所有表数据的性能可能会更差，但使用过滤器可能会得到更好的结果