Oracle 10g的隐含参数_complex_view_merging引发的性能问题-mysql教程-PHP中文網

首頁

資料庫

mysql教程

Oracle 10g的隐含参数_complex_view_merging引发的性能问题

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 05:35 PM

今天在Oracle 10g上碰到一个奇怪的问题，有一条sql在数据库1上很快，在数据库2上很慢，数据库2的数据是从数据库1上导的，数据量差

今天在Oracle 10g上碰到一个奇怪的问题，有一条sql在数据库1上很快，，在数据库2上很慢，数据库2的数据是从数据库1上导的，数据量差不多。

在数据库1上执行0.01s。

SQL> SELECT A.*,
2 B.INCREASE_ID,
3 B.TRANSACTION_ID,
4 B.LINK_CARD_ID,
5 B.VALIDATE_FLAG,
6 B.ASSET_VALUE_SHARING,
7 B.RELATED_DEVICE_ID,
8 B.PARENT_CARD_CODE,
9 B.PROJECT_VALUE,
10 B.DELETE_FLAG,
11 B.DEPRECIATION_ADJUST_VALUE,
12 T.TRANSACTION_MODE_CODE,
13 T.TRANSACTION_NO,
14 T.TRANSACTION_FROM,
15 T.FROM_MODEL,
16 (SELECT T.FULL_PATH
17 FROM AM_TECH_OBJECT_NODE_0900 T
18 WHERE T.TECH_OBJECT_ID = A.DEVICE_ID
19 AND T.NODE_TYPE = 2
20 AND ROWNUM = 1) AS FULL_PATH,
21 AAC.FULL_NAME CLASSIFY_FULL_PATH
22 FROM V_ASSET_CARD_0900 A,
23 GG_ASSET_INCREASE_ITEM B,
24 GG_ASSET_TRANSACTION T,
25 AM_ASSET_CLASSIFY AAC
26 WHERE A.CARD_ID = B.CARD_ID
27 AND B.TRANSACTION_ID = T.TRANSACTION_ID
28 AND A.CLASSIFY_ID = AAC.DEVICE_CLASSIFY_ID(+)
29 AND B.TRANSACTION_ID = '0101109514';
已用时间: 00: 00: 00.01
执行计划
----------------------------------------------------------
Plan hash value: 3643758043
-------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 21 | 24129 | 167 (0)| 00:00:03 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID | AM_TECH_OBJECT_NODE_0900 | 1 | 73 | 4 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | IDX_TECH_NODE_ID_0900 | 1 | | 3 (0)| 00:00:01 |
| 4 | NESTED LOOPS OUTER | | 21 | 24129 | 167 (0)| 00:00:03 |
| 5 | NESTED LOOPS | | 21 | 22533 | 146 (0)| 00:00:02 |
| 6 | NESTED LOOPS | | 20 | 12700 | 106 (0)| 00:00:02 |
| 7 | NESTED LOOPS | | 20 | 10900 | 46 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 20 | 2000 | 6 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID| GG_ASSET_TRANSACTION | 1 | 42 | 2 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | PK_GG_ASSET_TRANSACTION | 1 | | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID| GG_ASSET_INCREASE_ITEM | 20 | 1160 | 4 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | TRANSACTION_DETAIL_REF_TRANSAC | 20 | | 1 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | GG_ASSET_CARD_0900 | 1 | 445 | 2 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | PK_GG_ASSET_CARD_0303 | 1 | | 1 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | GG_ASSET_VALUE_0900 | 1 | 90 | 3 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | ID_FAV_CARD_VALIDITY_0303 | 1 | | 2 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | AM_ASSET_0900 | 1 | 438 | 2 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | PK_AM_ASSET_0900 | 1 | | 1 (0)| 00:00:01 |
| 19 | TABLE ACCESS BY INDEX ROWID | AM_ASSET_CLASSIFY | 1 | 76 | 1 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | PK_AM_ASSET_CLASSIFY | 1 | | 0 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM=1)
3 - access("T"."TECH_OBJECT_ID"=:B1 AND "T"."NODE_TYPE"=2)
10 - access("T"."TRANSACTION_ID"='0101109514')
12 - access("B"."TRANSACTION_ID"='0101109514')
14 - access("GG_ASSET_CARD"."CARD_ID"="B"."CARD_ID")
16 - access("GG_ASSET_VALUE"."CARD_ID"="GG_ASSET_CARD"."CARD_ID" AND
"GG_ASSET_VALUE"."VALIDITY_DATE_END"="GG_ASSET_CARD"."DECREASE_DATE")
18 - access("AM_ASSET"."DEVICE_ID"="GG_ASSET_CARD"."DEVICE_ID")
20 - access("AM_ASSET"."CLASSIFY_ID"="AAC"."DEVICE_CLASSIFY_ID"(+))
统计信息
----------------------------------------------------------
8 recursive calls
0 db block gets
28 consistent gets
0 physical reads
0 redo size
12384 bytes sent via SQL*Net to client
338 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

陳述

本文內容由網友自願投稿，版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容，請聯絡admin@php.cn

MySQL中的存儲過程是什麼？May 01, 2025 am 12:27 AM

存儲過程是MySQL中的預編譯SQL語句集合，用於提高性能和簡化複雜操作。 1.提高性能：首次編譯後，後續調用無需重新編譯。 2.提高安全性：通過權限控制限制數據表訪問。 3.簡化複雜操作：將多條SQL語句組合，簡化應用層邏輯。

查詢緩存如何在MySQL中工作？May 01, 2025 am 12:26 AM

MySQL查詢緩存的工作原理是通過存儲SELECT查詢的結果，當相同查詢再次執行時，直接返回緩存結果。 1）查詢緩存提高數據庫讀取性能，通過哈希值查找緩存結果。 2）配置簡單，在MySQL配置文件中設置query_cache_type和query_cache_size。 3）使用SQL_NO_CACHE關鍵字可以禁用特定查詢的緩存。 4）在高頻更新環境中，查詢緩存可能導致性能瓶頸，需通過監控和調整參數優化使用。

與其他關係數據庫相比，使用MySQL的優點是什麼？May 01, 2025 am 12:18 AM

MySQL被廣泛應用於各種項目中的原因包括：1.高性能與可擴展性，支持多種存儲引擎；2.易於使用和維護，配置簡單且工具豐富；3.豐富的生態系統，吸引大量社區和第三方工具支持；4.跨平台支持，適用於多種操作系統。

您如何處理MySQL中的數據庫升級？Apr 30, 2025 am 12:28 AM

MySQL數據庫升級的步驟包括：1.備份數據庫，2.停止當前MySQL服務，3.安裝新版本MySQL，4.啟動新版本MySQL服務，5.恢復數據庫。升級過程需注意兼容性問題，並可使用高級工具如PerconaToolkit進行測試和優化。

您可以使用MySQL的不同備份策略是什麼？Apr 30, 2025 am 12:28 AM

MySQL備份策略包括邏輯備份、物理備份、增量備份、基於復制的備份和雲備份。 1.邏輯備份使用mysqldump導出數據庫結構和數據，適合小型數據庫和版本遷移。 2.物理備份通過複製數據文件，速度快且全面，但需數據庫一致性。 3.增量備份利用二進制日誌記錄變化，適用於大型數據庫。 4.基於復制的備份通過從服務器備份，減少對生產系統的影響。 5.雲備份如AmazonRDS提供自動化解決方案，但成本和控制需考慮。選擇策略時應考慮數據庫大小、停機容忍度、恢復時間和恢復點目標。

什麼是mySQL聚類？Apr 30, 2025 am 12:28 AM

MySQLclusteringenhancesdatabaserobustnessandscalabilitybydistributingdataacrossmultiplenodes.ItusestheNDBenginefordatareplicationandfaulttolerance,ensuringhighavailability.Setupinvolvesconfiguringmanagement,data,andSQLnodes,withcarefulmonitoringandpe

如何優化數據庫架構設計以在MySQL中的性能？Apr 30, 2025 am 12:27 AM

在MySQL中優化數據庫模式設計可通過以下步驟提升性能：1.索引優化：在常用查詢列上創建索引，平衡查詢和插入更新的開銷。 2.表結構優化：通過規範化或反規範化減少數據冗餘，提高訪問效率。 3.數據類型選擇：使用合適的數據類型，如INT替代VARCHAR，減少存儲空間。 4.分區和分錶：對於大數據量，使用分區和分錶分散數據，提升查詢和維護效率。

您如何優化MySQL性能？Apr 30, 2025 am 12:26 AM

tooptimizemysqlperformance，lofterTheSeSteps：1）inasemproperIndexingTospeedUpqueries，2）使用ExplaintplaintoAnalyzeandoptimizequeryPerformance，3）ActiveServerConfigurationStersLikeTlikeTlikeTlikeIkeLikeIkeIkeLikeIkeLikeIkeLikeIkeLikeNodb_buffer_pool_sizizeandmax_connections，4）

See all articles