Oracle：极大地提高了查询性能
我有下一个查询，我正在尝试提高性能：
select atx.journal_id
,ab.c_date
from acct_batch ab
join acct_tx atx on ab.acct_id = atx.acct_id
and ab.batch_id = atx.batch_id
join journal j on j.journal_id = atx.journal_id
and j.journal_type_id = 6
join acct a on a.acct_id = atx.acct_id
and a.acct_type_id = 32
join payments p on p.payment_id = j.payment_id
join routing r on r.route_id = p.route_id
and r.acq_code = 'RZ_NS'
join acq_acct aa on aa.acq_code = r.acq_code
and aa.acq_acct_code = r.acq_acct_code
and aa.slc = 'MXM'
where ab.c_date between to_date(to_char('01-JUL-2015')) and last_day(sysdate);
我已经运行并查看了解释计划，总费用是7388.其中，最昂贵的部分是与journal表的连接，其成本为6319.
该表有大约160万行，有87个分区，其中只有两个包含行（分区6有140万，分区12有大约200k行）。
我尝试的第一件事就是重新编写查询以避免将实际的journal_type_id与6匹配的全扫描，但我想我的理解是不正确的，因为成本仍然是7388。
select atx.journal_id
,ab.c_date
from acct_batch ab
join acct_tx atx on ab.acct_id = atx.acct_id
and ab.batch_id = atx.batch_id
join (select
journal_id
, payment_id
from journal
where journal_type_id = 6) j on j.journal_id = atx.journal_id
join acct a on a.acct_id = atx.acct_id
and a.acct_type_id = 32
join payments p on p.payment_id = j.payment_id
join routing r on r.route_id = p.route_id
and r.acq_code = 'RZ_NS'
join acq_acct aa on aa.acq_code = r.acq_code
and aa.acq_acct_code = r.acq_acct_code
and aa.slc = 'MXM'
where ab.c_date between to_date(to_char('01-JUL-2015')) and last_day(sysdate);
我确实寻找了很多资源，其中一个决定我重新编写查询的原因是this video。
我仍然在积极寻找改善表现的方法，但我想我会在这里提出一个问题，可能会得到一些提示。
我认为视频中的人说应该做的第一件事是确定哪个是你的“驾驶表”（根据钥匙确定选择哪些行的那个），所以我'我目前正在寻找一种重写查询的方法，以尽可能地识别和使用这个驱动表及其索引。
我不知道我是否走上正轨，但如果你认为我应该继续，请阻止我。另外，请注意我是性能调优的初学者，实际上这是我的第一个。
感谢任何帮助。
更新
包含查询中使用的列的一些索引是：
╔════════════╦═══════════════╦════════════╦═══════════╦═════════════╦═══════════════════════════════════╗
║ Table ║ IndexName ║ Uniqueness ║ IndexType ║ Partitioned ║ Columns ║
╠════════════╬═══════════════╬════════════╬═══════════╬═════════════╬═══════════════════════════════════╣
║ Acct_Batch ║ Acct_Batch_PK ║ UNIQUE ║ NORMAL ║ NO ║ Acct_ID, Batch_ID ║
║ Acct_TX ║ Acct_TX_IDX ║ NONUNIQUE ║ NORMAL ║ YES ║ Acct_ID, Batch_ID ║
║ Acct_TX ║ Acct_TX_BIDX ║ NONUNIQUE ║ NORMAL ║ YES ║ Journal_ID, Acct_ID ║
║ Journal ║ Journal_PK ║ UNIQUE ║ NORMAL ║ YES ║ Journal_ID ║
║ Journal ║ JType_BIDX ║ NONUNIQUE ║ NORMAL ║ YES ║ Journal_Type_ID, Book_Date ║
║ Journal ║ JType_BIDX_2 ║ NONUNIQUE ║ NORMAL ║ YES ║ MCODE, Journal_Type_ID, Book_Date ║
║ Journal ║ JPay_BIDX ║ NONUNIQUE ║ NORMAL ║ YES ║ Payment_ID, Journal_ID ║
╚════════════╩═══════════════╩════════════╩═══════════╩═════════════╩═══════════════════════════════════╝
如果您需要查看有关其他表的更多索引或详细信息，请与我们联系。
示例解释计划：
-------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 160 | 7388 (1)| 00:01:29 | | |
|* 1 | FILTER | | | | | | | |
| 2 | NESTED LOOPS | | | | | | | |
| 3 | NESTED LOOPS | | 1 | 160 | 7388 (1)| 00:01:29 | | |
|* 4 | HASH JOIN | | 4 | 604 | 7380 (1)| 00:01:29 | | |
| 5 | NESTED LOOPS | | | | | | | |
| 6 | NESTED LOOPS | | 107 | 14338 | 7372 (1)| 00:01:29 | | |
|* 7 | HASH JOIN | | 27 | 3186 | 7298 (1)| 00:01:28 | | |
| 8 | NESTED LOOPS | | | | | | | |
| 9 | NESTED LOOPS | | 102 | 10302 | 978 (0)| 00:00:12 | | |
| 10 | NESTED LOOPS | | 11 | 638 | 37 (0)| 00:00:01 | | |
|* 11 | TABLE ACCESS BY INDEX ROWID | ACQ_ACCT | 11 | 253 | 4 (0)| 00:00:01 | | |
|* 12 | INDEX RANGE SCAN | AA_PK | 16 | | 2 (0)| 00:00:01 | | |
| 13 | TABLE ACCESS BY INDEX ROWID | ROUTES | 1 | 35 | 3 (0)| 00:00:01 | | |
|* 14 | INDEX RANGE SCAN | R_A_BIDX | 1 | | 2 (0)| 00:00:01 | | |
| 15 | PARTITION RANGE ALL | | 95 | | 84 (0)| 00:00:02 | 1 | 84 |
|* 16 | INDEX RANGE SCAN | P_R_ID_BIDX | 95 | | 84 (0)| 00:00:02 | 1 | 84 |
| 17 | TABLE ACCESS BY LOCAL INDEX ROWID| PAYMENTS | 9 | 387 | 100 (0)| 00:00:02 | 1 | 1 |
| 18 | PARTITION RANGE ALL | | 107K| 1782K| 6319 (1)| 00:01:16 | 1 | 87 |
|* 19 | TABLE ACCESS FULL | JOURNAL | 107K| 1782K| 6319 (1)| 00:01:16 | 1 | 87 |
| 20 | PARTITION RANGE ITERATOR | | 4 | | 2 (0)| 00:00:01 | KEY | KEY |
|* 21 | INDEX RANGE SCAN | ATX_A_IDX | 4 | | 2 (0)| 00:00:01 | KEY | KEY |
| 22 | TABLE ACCESS BY LOCAL INDEX ROWID | ACCT_TX | 4 | 64 | 3 (0)| 00:00:01 | 1 | 1 |
|* 23 | INDEX RANGE SCAN | AB_B_A_IDX | 5006 | 85102 | 8 (0)| 00:00:01 | | |
|* 24 | INDEX UNIQUE SCAN | ACC_PK | 1 | | 1 (0)| 00:00:01 | | |
|* 25 | TABLE ACCESS BY INDEX ROWID | ACCT | 1 | 9 | 2 (0)| 00:00:01 | | |
-------------------------------------------------------------------------------------------------------------------------------
2 个答案:
答案 0 :(得分：1)
首先检查您的统计信息是否已更新：优化程序在很大程度上取决于统计信息！ 其次，您应该说明使用此查询获得的行数：根据每个条件选择的行数，完全扫描可能比索引搜索更好。
答案 1 :(得分：0)
因此，在仔细检查代码后，根据查询的SELECT部分列出的列显示的数据，我观察到最后一个连接表没有带来任何贡献（不需要任何数据）从它显示到输出。
join acq_acct aa on aa.acq_code = r.acq_code
and aa.acq_acct_code = r.acq_acct_code
and aa.slc = 'MXM'
因此，我将此查询移至EXISTS子句并重新运行查询。我修改后的查询如下所示：
select atx.journal_id
,ab.c_date
from acct_batch ab
join acct_tx atx on ab.acct_id = atx.acct_id
and ab.batch_id = atx.batch_id
join journal j on j.journal_id = atx.journal_id
and j.journal_type_id = 6
join acct a on a.acct_id = atx.acct_id
and a.acct_type_id = 32
join payments p on p.payment_id = j.payment_id
join routing r on r.route_id = p.route_id
and r.acq_code = 'RZ_NS'
where ab.c_date between to_date(to_char('01-JUL-2015')) and last_day(sysdate)
and exists (select 1
from acq_acct aa
where aa.acq_code = r.acq_code
and aa.acq_acct_code = r.acq_acct_code
and aa.slc = 'MXM');
这有助于将查询成本从7388提高到292，这是一个巨大的差异。
希望我对此有了正确的理解，我的解释也是有道理的。
如果有人认为我的结论已经结束或者是“逻辑推理”＃34;是不正确的，请发表评论（目前，我的结论/解释对我来说很有意义。）
相关问题
最新问题
- 我写了这段代码，但我无法理解我的错误
- 我无法从一个代码实例的列表中删除 None 值，但我可以在另一个实例中。为什么它适用于一个细分市场而不适用于另一个细分市场？
- 是否有可能使 loadstring 不可能等于打印？卢阿
- java中的random.expovariate()
- Appscript 通过会议在 Google 日历中发送电子邮件和创建活动
- 为什么我的 Onclick 箭头功能在 React 中不起作用？
- 在此代码中是否有使用“this”的替代方法？
- 在 SQL Server 和 PostgreSQL 上查询，我如何从第一个表获得第二个表的可视化
- 每千个数字得到
- 更新了城市边界 KML 文件的来源？