Ibm midrange iSeries DB2有好的优化器吗？

MS SQL开发者在这里涉入iSeries DB2

我被要求重新编写一些报表SQL查询，这些查询需要花费很长时间才能运行，而且它们非常庞大，连接了几十个表等等

---

然而，当我使用典型的MS SQL优化步骤（例如用联接替换NOT EXISTS）来实现这一点时，我最初并没有看到任何改进。我应该麻烦一下，还是优化器正在处理这样明显的事情？

DB/2与MS-SQL完全不同，我不希望许多手动优化会产生相同的影响

有许多因素与DB/2性能和优化有关。我建议从关于的文档开始

例如，通过运行查询应该可以提供更清晰的答案

---

---

也许最明显的检查是确保您的联接具有良好的索引。如果没有，则创建它们。索引对DB2fori的性能影响要小得多。

如果您只看到查询，就会看到。他们很可怕。很遗憾，我只有到服务器的ODBC连接。@ajeh您通常可以直接从服务器安装iSeries Access，并使用ODBC凭据进行连接。这应该可以让你访问所需的分析工具。我可以访问一个带有VisualExplain的框，它现在正在对查询连续运行explain 50分钟。查询本身大约需要15分钟。所以，我回到了问题的第1步：对于DB2优化器来说，使用联合和存在/不存在的大量嵌套选择有多糟糕？如果这是MS SQL，我将使用带有临时表的存储过程重写它。DB2会从这种方法中受益吗？IBM的DB2fori性能专家通常会引导您远离临时表，而是建议使用公共表表达式。适当的指数是一个至关重要的因素。JamesA提供了一个很好的link.FWIW，在这个网站上，我们试图[专注于特定的编程问题][。我们通常更喜欢在我们的[DBA网站]上发布更广泛的数据库问题[.那里有许多相同的人，但你可能会听到一些更专业的技术专家的声音。很高兴知道，谢谢！我相信是这样的。问题是，这些查询绝对不可管理，因为它们包括几十个连接的子选择，其中一些是联合，许多包括

存在的地方

和

whoere not exists

。以我的拙劣经验，

exists

逻辑与logic.YMMV中的join或

相比，性能往往很差。该应用程序实际上没有任何索引-它们使用键控逻辑文件。我尝试用联接替换所有exists/not exists，但没有任何区别。只要是逻辑文件[LF]是键控的，它包含（或共享）一个IBM i索引，该索引的用途与DB2索引相同，但效率不一定高可能会导致系统使用较旧的CQE优化器，而不是SQE。在这种情况下，查询PFs，优化器将选择最佳可用索引（或LF）。许多LF具有WHERE逻辑，如果在基于PF的查询中没有，可能会取消它们的资格。您使用的是哪个操作系统版本？您的导航器是否处于该状态（或更高版本）发行版，外加service pack？在SQL Server上运行多长时间？