我正在创建Interactive Grid report。
我有一个非常复杂的SQL查询。它有3个SQL查询部分，语法如下所示。
WITH
QUERY1 AS
-- QUER1 --
QUERY2 AS
-- QUER1 --
QUERY3 AS
-- QUER1 --
SELECT
-- COLUMNS --
FROM
(
QUERY1 WHERE NVL(QUERY, 'A') = 'A'
UNION ALL
QUERY2 WHERE NVL(QUERY, 'B') = 'B'
UNION ALL
QUERY3 WHERE NVL(QUERY, 'C') = 'C'
)
WHERE
-- CONDITIONS --它有57列，使用14个表。即使是sql查询的大小也是大约30 k个字符。我已经优化了查询。根据执行后计划，成本低于2000，根据解释计划，成本低于150。其中只有3个会导致Table Access Full。当没有传递参数或apex-item值时也是如此。
-------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1740 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 2 (0)| 00:00:01 |
|* 2 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 1 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID | PLP_TBL | 1 | 72 | 2 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | PK_PLP_TBL | 1 | | 1 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 2 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 1 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID | PTD_TBL | 1 | 17 | 2 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | PTD_TBL_DT | 1 | | 1 (0)| 00:00:01 |
|* 9 | FILTER | | | | | |
|* 10 | FILTER | | | | | |
| 11 | NESTED LOOPS | | 100 | 260K| 1640 (2)| 00:00:01 |
| 12 | NESTED LOOPS | | 100 | 260K| 1640 (2)| 00:00:01 |
|* 13 | HASH JOIN RIGHT OUTER | | 100 | 252K| 1608 (2)| 00:00:01 |
| 14 | VIEW | VW_ORE_115E4D93 | 96 | 8064 | 393 (1)| 00:00:01 |
| 15 | UNION-ALL | | | | | |
|* 16 | FILTER | | | | | |
| 17 | NESTED LOOPS | | 1 | 64 | 3 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | 1 | 64 | 3 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID BATCHED | RD_TBL | 1 | 48 | 2 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | RD_TBL_I1 | 1 | | 2 (0)| 00:00:01 |
|* 21 | INDEX UNIQUE SCAN | PK_RH_TBL | 1 | | 0 (0)| |
|* 22 | TABLE ACCESS BY INDEX ROWID | RH_TBL | 1 | 16 | 1 (0)| 00:00:01 |
|* 23 | FILTER | | | | | |
|* 24 | HASH JOIN | | 95 | 6080 | 390 (1)| 00:00:01 |
|* 25 | TABLE ACCESS FULL | RH_TBL | 71 | 1136 | 177 (2)| 00:00:01 |
|* 26 | TABLE ACCESS FULL | RD_TBL | 1 | 48 | 3 (0)| 00:00:01 |
| 27 | VIEW | | 100 | 244K| 1214 (2)| 00:00:01 |
| 28 | UNION-ALL | | | | | |
| 29 | VIEW | VW_ORE_87C0170C | 68 | 42636 | 893 (2)| 00:00:01 |
| 30 | UNION-ALL | | | | | |
|* 31 | FILTER | | | | | |
| 32 | NESTED LOOPS | | 1 | 209 | 4 (0)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 209 | 4 (0)| 00:00:01 |
| 34 | TABLE ACCESS BY INDEX ROWID BATCHED | AD_TBL | 1 | 177 | 2 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | AD_TBL_I1 | 1 | | 2 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | PK_AH_TBL | 1 | | 1 (0)| 00:00:01 |
|* 37 | TABLE ACCESS BY INDEX ROWID | AH_TBL | 1 | 32 | 2 (0)| 00:00:01 |
|* 38 | FILTER | | | | | |
| 39 | NESTED LOOPS | | 67 | 14003 | 889 (2)| 00:00:01 |
| 40 | NESTED LOOPS | | 70 | 14003 | 889 (2)| 00:00:01 |
| 41 | TABLE ACCESS BY INDEX ROWID BATCHED | AH_TBL | 10 | 320 | 799 (3)| 00:00:01 |
|* 42 | INDEX SKIP SCAN | PAH_I1 | 10 | | 789 (3)| 00:00:01 |
|* 43 | INDEX RANGE SCAN | PK_AD_TBL | 7 | | 2 (0)| 00:00:01 |
| 44 | TABLE ACCESS BY INDEX ROWID | AD_TBL | 7 | 1239 | 9 (0)| 00:00:01 |
| 45 | NESTED LOOPS OUTER | | 30 | 17010 | 298 (1)| 00:00:01 |
| 46 | NESTED LOOPS OUTER | | 30 | 16290 | 297 (1)| 00:00:01 |
| 47 | NESTED LOOPS OUTER | | 30 | 15570 | 296 (1)| 00:00:01 |
| 48 | NESTED LOOPS OUTER | | 30 | 14850 | 295 (1)| 00:00:01 |
| 49 | VIEW | VW_JF_SET$3641B155 | 30 | 14130 | 294 (1)| 00:00:01 |
| 50 | UNION-ALL | | | | | |
|* 51 | FILTER | | | | | |
| 52 | NESTED LOOPS | | 29 | 4669 | 190 (1)| 00:00:01 |
| 53 | NESTED LOOPS | | 29 | 4669 | 190 (1)| 00:00:01 |
|* 54 | TABLE ACCESS FULL | MAH_TBL | 29 | 783 | 103 (1)| 00:00:01 |
|* 55 | INDEX RANGE SCAN | MAD_TBL_INDEX2 | 1 | | 2 (0)| 00:00:01 |
|* 56 | TABLE ACCESS BY INDEX ROWID | MAD_TBL | 1 | 134 | 3 (0)| 00:00:01 |
|* 57 | FILTER | | | | | |
| 58 | NESTED LOOPS | | 1 | 161 | 104 (1)| 00:00:01 |
| 59 | NESTED LOOPS | | 1 | 161 | 104 (1)| 00:00:01 |
|* 60 | TABLE ACCESS FULL | MAH_TBL | 1 | 27 | 103 (1)| 00:00:01 |
|* 61 | INDEX RANGE SCAN | MAD_TBL_INDEX2 | 1 | | 1 (0)| 00:00:01 |
|* 62 | TABLE ACCESS BY INDEX ROWID | MAD_TBL | 1 | 134 | 1 (0)| 00:00:01 |
| 63 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 1 (0)| 00:00:01 |
|* 64 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 0 (0)| |
| 65 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 1 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 0 (0)| |
| 67 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 1 (0)| 00:00:01 |
|* 68 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 0 (0)| |
| 69 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 1 (0)| 00:00:01 |
|* 70 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 0 (0)| |
|* 71 | FILTER | | | | | |
| 72 | NESTED LOOPS OUTER | | 2 | 542 | 23 (0)| 00:00:01 |
| 73 | NESTED LOOPS OUTER | | 2 | 494 | 22 (0)| 00:00:01 |
| 74 | NESTED LOOPS OUTER | | 2 | 446 | 21 (0)| 00:00:01 |
| 75 | NESTED LOOPS OUTER | | 2 | 398 | 20 (0)| 00:00:01 |
| 76 | NESTED LOOPS | | 2 | 350 | 19 (0)| 00:00:01 |
|* 77 | TABLE ACCESS FULL | PAH_TBL | 4 | 100 | 11 (0)| 00:00:01 |
|* 78 | TABLE ACCESS BY INDEX ROWID BATCHED| PAD_TBL | 1 | 150 | 2 (0)| 00:00:01 |
|* 79 | INDEX RANGE SCAN | PAD_TBL_INDEX2 | 1 | | 1 (0)| 00:00:01 |
| 80 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 1 (0)| 00:00:01 |
|* 81 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 0 (0)| |
| 82 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 1 (0)| 00:00:01 |
|* 83 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 0 (0)| |
| 84 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 1 (0)| 00:00:01 |
|* 85 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 0 (0)| |
| 86 | TABLE ACCESS BY INDEX ROWID | CD_TBL | 1 | 24 | 1 (0)| 00:00:01 |
|* 87 | INDEX UNIQUE SCAN | PK_CD_TBL | 1 | | 0 (0)| |
|* 88 | INDEX UNIQUE SCAN | PK_EM_TBL | 1 | | 0 (0)| |
|* 89 | TABLE ACCESS BY INDEX ROWID | EM_TBL | 1 | 76 | 1 (0)| 00:00:01 |
| 90 | NESTED LOOPS | | 1 | 27 | 3 (0)| 00:00:01 |
| 91 | TABLE ACCESS BY INDEX ROWID | AU_TBL | 1 | 9 | 2 (0)| 00:00:01 |
|* 92 | INDEX UNIQUE SCAN | AU_TBL_PK | 1 | | 1 (0)| 00:00:01 |
|* 93 | INDEX RANGE SCAN | AULA_TBL | 1 | 18 | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------------在SQL开发者上，如果检查1年的数据，这可以在2秒内加载300万条记录。
但在apex上，加载一个月的数据需要10多分钟。我用的是19.1.我已经尝试了所有3种类型的顶点报告。
调试器日志显示查询本身的处理时间过长。
我也试过，创建一个非常简单的页面。它没有任何js代码，DA。列类型为默认的文本/日期/数字。
有时候我也会得到502 Proxy error。
现在有趣的部分，如果我评论任何两个关闭下面的语句，那么我得到的结果在不到1分钟的一年，以及.
(
SELECT * FROM QUERY1 WHERE NVL(:QUERY, 'A') = 'A'
UNION ALL
SELECT * FROM QUERY2 WHERE NVL(:QUERY, 'B') = 'B'
UNION ALL
SELECT * FROM QUERY3 WHERE NVL(:QUERY, 'C') = 'C'
)然而，即使没有注解并传递任何值“A”/“B”/“C”，仍然会导致一个月的相同性能问题。
有什么想法可以解决这个问题吗？
3条答案
按热度按时间hujrc8aj1#
在大多数情况下，这是由于页面的分页设置。如果分页设置为“X TO Y FROM Z”，那么apex引擎将必须首先检索所有行（正如您在调试中看到的那样）。将其更改为“无分页”或“行X到Y”。
dxxyhpgq2#
如果您只想尽快修复查询，请尝试简单的ROWNUM trick。这是解决“这些查询独立运行时速度快，但组合起来运行时速度慢”这一常见问题的最快方法。
如果您想深入研究，并真正深入了解性能问题，您将需要更强大的工具。您需要找到每个 * 操作 * 的 * 实际 * 运行时间和基数，以便进行更深入的研究。最好的两种方法通常是the
/*+ gather_plan_statistics */hint or create a SQL Monitor Report.您发布的解释计划仅显示Oracle的估计。Oracle * 认为 * 查询执行的每个操作将花费1秒，并返回最多100行。由于您的查询需要花费几分钟的时间，因此这些估计中至少有一个明显错误。大多数人只是试图猜测计划的哪一部分是缓慢的。使用实际数字，您可以缩小问题范围，将重点放在少量操作上。但即使有了这些知识，解决问题仍然需要很长时间。
ikfrs5lh3#
我找到了解决办法。
在所有3个子查询中使用了一个自定义函数。我只是在main select语句中使用了它。
不过，我正面临一个顶点报告下载问题。现在数据加载在秒，但一旦点击下载，它开始后10-15分钟。在这之间什么都没有发生。甚至在控制台、调试、网络等方面都没有写任何语句。