我有一个查询，从SQL执行时表现出色。
它是表和查询之间的联接。这两个表都有近400万条记录。
我试图在doc表上提供位图索引。当我从蟾蜍那里看到时，解释计划确实表明他们正在很好地帮助加入。
我还提供了2条其他提示，以查看它们是否有帮助。一种是直接路径APPEND，另一种是利用pda上现有的BTree索引。
当针对来自SQL的替换变量运行此查询时，结果是瞬时的，但是过程中的同一查询将花费8秒钟或更长时间。
除了DBA尚未屈服的《程序》计划之外，如果您想到任何明显的遗漏，我会怎么想？提前致谢。
INSERT /*+ APPEND */ INTO tmp_search_gross_docs (document_id, last_name, first_name, person_doc_association_id, association_date) SELECT /*+INDEX(pda IDX_DOC_PDOC_DOCID ) USE_NL(pda doc) */ pda.document_id, last_name, first_name, person_doc_association_id, association_date FROM pda, (SELECT /*+INDEX_COMBINE(attr IDX_BMP_SEARCH_FN,IDX_BMP_SEARCH_LN)*/ document_id, last_name, first_name FROM doc attr WHERE first_name LIKE l_first_name OR last_name LIKE l_last_name) doc WHERE pda.document_id = doc.document_id; ) doc WHERE pda.document_id = doc.document_id;
解释计划（从Toad获取绑定变量）
插入语句ALL_ROWSC费用：1,086,010字节：15,309,420基数：364,510
11 LOAD AS SELECT TMP_SEARCH_GROSS_DOCS
按索引行表PDA进行10表访问成本：3字节：20基数：1
9嵌套循环成本：1,086,010字节：15,309,420基数：364,510
7按索引行表访问权限进行的表访问成本：23,893字节：8,019,220基数：364,510
6位图转换为行
5位图或
2位图合并
1位图索引范围扫描索引（位图）IDX_BMP_SEARCH_FN
4位图合并
3位图索引范围扫描索引（位图）IDX_BMP_SEARCH_LN
8 INDEX RANGE SCAN INDEX IDX_PDA_EXP_DOC成本：2基数：1
基数364,510似乎不对，因为该表包含3738562行，并且对于WHERE中列的替换值，计数仅为8892。
但是同样，这个计划至少告诉我，正确的索引正在使用，并且可以从Toad编辑器中快速运行。
PL / SQL的实际计划仍然不可用。
不知道这是否添加一些有价值的信息。但是思想仍然会编辑。谢谢
最佳答案
首先，我不认为使用append插入GTT有任何逻辑。我可能是错的，但是据我所知，append绕过缓冲区缓存并直接写入文件，它在高水位线上方写入，并且不允许在提交之前进行查询。
GTT不在常规数据文件上-它在临时文件上，并且在提交时被截断（默认设置）。
我认为，如果您在查询后不需要处理数据，请考虑将ref游标返回给应用程序。基本上是同一件事-这种方式实现了许多DAL层。
如果您仍然需要GTT，我将检查我的临时文件分配，包括大小和实际磁盘-您的DBA可能将它们放在了不同的设备上。
关于sql - 从PL/SQL插入到临时表GTT的速度非常慢，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/15978395/