我有一个包含 800 万行的事实表，每月增加 100 万行。该表已包含其上的索引。IBM Cognos 环境使用该表来生成报告。目前我正在寻找优化表 SELECT 语句的方法。
作为第一次尝试，我对表进行了分区（每个分区具有相同的行分布）并且查询适用于分区，但由于某种原因，我得到了相同甚至更差的性能，这很奇怪。每个查询只影响一个分区。有人可以解释如何优化吗？
我想到的第二个想法是将事实表实现为索引组织表，但它必须将所有列作为主键。这可以吗？会有性能提升吗？
第三个想法是以包含从星型模式连接的所有列的方式实现事实表。会有性能提升吗？
编辑：这是执行计划：
在创建包含分区标准的索引之后，我设法将事实表 FT_COSTS 的访问时间减少了 3 倍（成本为 42000，现在为 14900），但在此之前，我得到的结果比未分区表更差。我用这个链接来解决我的分区问题Range partition skip check
从我现在看到的情况来看，主要瓶颈是 GROUP BY ，它将成本从 34000 提高到 85 000 ，增加了一倍以上。有没有人对此有解决方法的想法？
分区修剪可能是一个棘手的问题。
您有查询的解释计划吗？它显示PARTITION RANGE SINGLE吗？如果不是，则查询将忽略分区。如果是这样，那么您还有其他问题。
我的钱花在了这些分支中的第一个上：物理分区会重新排序表。这意味着不符合分区策略的执行计划可能比针对未分区表的执行计划运行得更差。
为了进一步了解这一点，我们需要查看一些细节。至少您的表的分区子句和您所说的查询部分适用于这种方法。解释计划也会很有帮助。你给我们的细节越多越好：调优是关于细节的，因为每种情况都是特殊的。
“你能解释一下为什么group by的成本这么高，以及如何降低成本吗？”
GROUP BY 表示排序。如果您有大量数据，这可能会很昂贵，因为它需要内存（或磁盘写入）和 CPU 周期。
至于降低成本，对我没见过的查询提供建议有点困难。我能说的是：查询需要时间，而使用大量数据的查询需要更长的时间。调优的秘诀是了解给定查询的合理时间量。如果查询运行得足够快，则成本无关紧要。
GROUP BY 实际上是什么 GROUP BY ？
解释计划表明散列连接中有 1,238,320 行进入 GROUP BY，相同的行数从顶级 SELECT 中出来。这表明优化器实际上并不相信您会在这里进行任何真正的聚合。
降低 group by 的成本通常需要您创建 pe-computed 聚合，通常是通过创建一个或多个物化视图。
如果您在执行计划的末尾看到，则表明表 FT_COSTS 已完全访问（表访问已满）。由于它是完全可访问的，因此在您为获取数据而添加的所有连接中，最终成本似乎很大。我的建议是为表放置适当的索引，以便它引用索引而不是整个表来访问数据，然后看到你的性能发生了巨大的变化！！！！！！