1

有一个 SQL 查询连接一个临时表和一个视图（连接两个表）：

select main.*
  from tmp_table_srt sub -- temporary table
  inner join vw_s_ad_conjunct main -- joining tables M_S_AD_CONJUNCTION and M_S_AD
    on sub.I_SRTREF = 94646 and
       sub.O_ID = main.ID
  where ASCJTREF = 1678744 and
        SOURCEADSREF = 1193467 and
        isnodummy(ID) = 1

它有一个查询计划，对我来说看起来不错：

PLAN JOIN (SUB INDEX (UNQ_TMP_TABLE_SRT), MAIN ADS INDEX (PK_M_S_AD), MAIN ADSCJT INDEX (FK_M_S_AD_CONJUNCTION_SUBADS))

在我的数据库 IDE（即 IBExpert）中，此查询的执行速度足够快（不到一秒）。但是在客户端应用程序中会发生这种情况：当查询被执行时，服务器临时目录完全运行。之前大约有 23 GB 的可用空间。一旦没有可用空间，应用程序就会崩溃。

起初，我认为是查询导致的。但后来我检查，当通过我的数据库 IDE 执行并使用具有良好索引的查询计划时，它运行速度很快（不会溢出临时目录）。此外，我认识到这不是在打开查询时发生的，而是在打开查询后isc_dsql_sql_info()由FIBPlus数据库组件进行 API 调用时发生的（为了获取别名 - 我想）。

函数请求参数填充如下：

InfoRequest[0]:= AnsiChar(isc_info_sql_select);         // 4
InfoRequest[1]:= AnsiChar(isc_info_sql_describe_vars);  // 7
InfoRequest[2]:= AnsiChar(isc_info_sql_sqlda_seq);      // 9
InfoRequest[3]:= AnsiChar(frb_info_sql_relation_alias); // 25
InfoRequest[4]:= AnsiChar(isc_info_sql_describe_end);   // 8

这个 API 调用的某些原因导致 Firebird 需要大量的临时空间。不幸的是，我几乎没有发现任何关于这个函数的信息（除了这个Interbase API 指南，它没有告诉我任何关于请求值的信息）。

Maybe there are some Firebird or Interbase experts here, who can help me to find out what causes this problem. I use Firebird (classic server) 2.5.5.26952 and fbclient.dll 2.5.5.26952

4

1 回答 1

1

[these] client API calls can't result temp allocation at server. Firebird allocates temp space in several known cases: - creating index (not your case) - sorting query result (not your case, sinse there is no SORT word in PLAN) - using function LIST (seems not your case) - ...

So, maybe your application in addition executes some another query, that results huge sorting or temp usage. Or, you gave us wrong query :-) Btw, what are the file names (and their size) that allocates your temp? Can you turn on monitoring (using FIBPlus) to check what goes to server with this query?

于 2016-03-31T21:47:43.510 回答