从表中选择语句，没有长时间运行的连接或过滤器。如何优化答案

【问题标题】：Select statement from a table, with no joins or filters running long. How to optimise从表中选择语句，没有长时间运行的连接或过滤器。如何优化
【发布时间】：2021-08-22 10:10:18
【问题描述】：

尝试从全局临时表中优化 select 语句，没有连接。我尝试对所有被选择的列和操作提示进行索引。删除了索引，只是创建了一个主键索引并用于操作提示。两者都没有运气。请建议..

SELECT  /*+ INDEX(fim_mp_po_lcm_gt_tst,PK_PO_HEADER_ID_TST) */
fmpl.operating_unit "Business Unit",
fmpl.period_name "Period Name",
TO_CHAR(SYSDATE,'DD-MON-YYYY HH24:MI:SS')  "Report Date/Time" ,
fmpl.po_number "PO Number",
fmpl.po_brand "Brand",
fmpl.po_channel "Channel",
fmpl.dest_country "Destination",
fmpl.po_status "PO Status",
fmpl.currency_code "Currency",
TO_CHAR(fmpl.elc_Date,'DD-MON-YYYY') "ELC Date",
fmpl.elc_amt "Current Period ELC",
fmpl.alc_amt "Current Period ALC",
fmpl.variance_Amt "Variance Booked"
FROM FIM_MP_PO_LCM_GT_TST fmpl

显然索引没有被使用

SQLQuery:EXPLAIN PLAN SET STATEMENT_ID = 'dm_plan_Q_210604_114114' FOR 
SELECT 
fmpl.operating_unit "Business Unit",
fmpl.period_name "Period Name",
TO_CHAR(SYSDATE,'DD-MON-YYYY HH24:MI:SS')  "Report Date/Time" ,
fmpl.po_number "PO Number",
fmpl.po_brand "Brand",
fmpl.po_channel "Channel",
fmpl.dest_country "Destination",
fmpl.po_status "PO Status",
fmpl.currency_code "Currency",
TO_CHAR(fmpl.elc_Date,'DD-MON-YYYY') "ELC Date",
fmpl.elc_amt "Current Period ELC",
fmpl.alc_amt "Current Period ALC",
fmpl.variance_Amt "Variance Booked"

FROM "FIM_MP_PO_LCM_GT_TST" fmpl
SQL Query Timeout: 600
Number of SQL Executions: 1
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------
Plan hash value: 1118455586
 
--------------------------------------------------------------------------------------------------
| Id  | Operation                 | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |                      |     1 |   454 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS STORAGE FULL| FIM_MP_PO_LCM_GT_TST |     1 |   454 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

【问题讨论】：

如果您选择没有连接或过滤器的整个表，全表扫描是最快的，不要尝试使用索引。
但显然它需要很长时间，然后在 3 小时后超时，（从 BI 发布者数据模型运行此）而填充表的插入语句大约需要 15 分钟。
听起来问题出在 BI Publisher 端，而不是表或数据？
可能是..但是对于较小的数据集，它只是在几秒钟内返回值..
更有理由怀疑 BI Publisher 方面；您是否尝试过直接在托管数据库的服务器上执行查询？我见过很多次是网络/应用程序设置减慢了速度。是时候隔离发生缓慢的地方了。如果您edit 您的问题有更多详细信息，例如“通过 BI Publisher 返回 1,000 行的查询需要 23 秒，通过 SQLPlus 需要 1.2 秒，返回 100,000 行的查询在 BI 中需要 3.3 小时和 3.3 分钟在 SQLPLus 中"

标签： oracle optimization indexing plsql

【解决方案1】：

您可以在查询中使用 PARALLEL 提示

基本示例：

SELECT /*+ PARALLEL(emp,4) / COUNT() FROM emp;

【讨论】：

如果并行选项获得许可，这将有所帮助。但是您的示例与原始问题略有不同，因为该示例返回一行，即表中所有行的count(*)。在该特定查询中，可以（也）使用索引来提高性能。对于该示例，索引选项可能比并行更好。

【解决方案2】：

使用来自 cmets 的信息，通过 BI 发布者数据模型的查询似乎是导致查询运行时间过长的原因，正如 Alex 所怀疑的那样。 Mat 正确地指出，如果您的查询需要表中的所有行，那么没有索引会有所帮助。

当通过某些软件包（例如 BI Publisher）运行查询时，这是检查查询是否运行缓慢的首要事项之一：尝试通过 SQL* 等程序直接在服务器上运行查询（如果可能）加号或 SQL 开发人员。这将消除（大部分）网络开销或由于客户端软件配置等原因的可能性。

即使您必须通过网络而不是直接在服务器上通过 SQLPlus 运行查询，您也可以使用 SQLPlus 命令set autotrace traceonly 来运行查询，但不返回网络中的数千/数百万行。

这种方法有助于证明原始海报问题的原因，正如 OP 在评论中指出的那样，在此处复制以方便参考：

直接使用 sql developer 在 DB 中查询，17k 条记录不到 1 秒完成，而 BIP 则超过 3 小时

曾经我不得不处理一个对于大多数查询来说都很慢的应用程序；不是软件，也不是数据库，而是通信层软件，IBM 的 MQ 消息队列软件，被配置为每隔秒发送一个“保持清醒”数据包，并且一直保持唤醒数据包大约为 1,500 字节，而每隔分钟可能有 100 个字节可以工作。因此，56 KB 网络链接（是的，很久以前）上的数百名用户，所有这些额外的数据包都是罪魁祸首。

【讨论】：