通过StarSQL访问DB2 -效率.输出参数或选择查询
本文关键字：参数 选择 查询 输出 效率 StarSQL 访问 DB2 通过 | 更新日期: 2023-09-27 18:08:00
我正在编写一些代码，用于查询运行在老式大型机上的老式DB2数据库。查询必须用StarSQL编写，这样做的目的是大大减少MIP对通过Command.Text传入的当前查询的使用。
对于那些不知道的人，您会根据大型机上的CPU使用率(MIP)收取费用(很多!)，因此您希望事情尽可能高效地运行。你真的不想说"Select * From TableA"并将其作为CommandType传递。文本到数据库，因为它需要编译语句，然后返回结果。您需要将其保存为一个过程(已经编译过)，并去掉所需列的*。
那么，我的问题。我不能自己回答这个问题，因为我们的大型机专家正在度假……
我有一个返回~30列的过程。是通过Select查询返回这些参数更有效，还是将它们作为输出参数返回更有效?这是通过存储过程实现的。
我不担心c#代码的长度，但在那该死的大型机上的效率。
我需要考虑以下事情:
SELECT PHNS.CLNT_INTERNL_KY as CLNT_INTRNL_KY
使用额外的CPU占用来将列名应用到该列，但是使用游标将其保存为输出参数会更有效吗?
如果您还需要其他信息，请告诉我。
欢呼,
(有"可以"在标签上的starSQL标签，但唉，我不是1500点…)
许多查询api不允许使用存储过程，但是如果您有这个选择，使用存储过程可以在编译时解析和优化查询一次，而不是在每次执行时都使用，从而节省一些CPU时间。如果没有，您仍然可以从动态SQL语句的缓存中获益。动态语句的访问计划暂时存储在包缓存中，因此，如果很快遇到相同的字节对字节相同的语句(包括参数标记和文字值)，DB2将重用包缓存中的访问计划，而不是从头开始重新优化它。
对于经常使用不同文字值运行的语句，使用存储过程可以节省大量的编译时间。如果输入参数是可选的或者变化很大(比如灵活的搜索)，那么存储过程可能会在编译时产生不希望看到的访问计划，因为它不知道在运行时将填充哪些参数。在这些情况下，存储过程可能需要在运行时通过REOPT策略重新优化查询，但这种方法显然会减少预编译的节省。
我建议使用DB2的EXPLAIN工具来确定查询工作负载中的实际成本(编译、扫描和排序)。如果查询扫描了大量的行，那么计算每一行的CPU成本很快就会超过优化动态查询的成本。发出SELECT *的查询通常会阻止优化器利用可以用更少的I/O操作满足相同查询的索引。WHERE子句中的过滤器和连接谓词(或缺少它们)也可以阻止优化器选择索引。