Ⅰ oracle sql執行計劃怎麼分析
在發現一個語句的執行計劃有異常的時候，通常會生成一個sqlrpt看看使用的執行計劃是否正確，如何來判斷執行計劃是否正確，將通過以下幾個步驟來判斷：
1.先查看sql語句的結構，看語句中連接是union，還是等值連接還是左、右連接,再看連接中的表數量。
2.查看執行計劃中出現異常的部分。
3.查看各表的索引情況及表是否是分區的，在where條件上使用的索引列是否正確，看統計分析表中對表的分析結果是否正確
4.分析表的用途，表的數據日增長量。
5.分析為什麼會出現異常的執行計劃。
跟蹤執行計劃的方法：
(1) set autotrace on explain 只顯示查詢結果和執行計劃
set autotrace on statistic 只顯示查詢結果統計信息
set autotrace on 顯示前兩者
set autotrace traceonly 不顯示查詢結果，只顯示執行計劃和統計信息
set autotrace off 關閉跟蹤
要使用autotrace，必須在sqlplus裡面使用，且使用的是sys用戶。
（2）可以使用explain plan for select * from c_cons 可以解析執行計劃，然後通過select * from table(dbms_xplain.display(null,null,』outline』,null));來顯示執行計劃。
（3）使用工具Toad for oracle使用sql_id來生成執行計劃
Ⅱ oracle sql的執行計劃如何查看
方法/步驟
打開PL/SQL Developer軟體，請確保plsql能夠成功連接到一個oracle資料庫。
在PL/SQL Developer中寫好一段SQL代碼，按F5，或者點擊「執行執行計劃」圖標，PL/SQL Developer會自動打開執行計劃窗口，顯示該SQL的執行計劃。
可以看到窗口上方是sql語句，下方顯示執行計劃表格。表格的列主要包含描述、用戶、對象、成本花費、IO開銷等，表格，當然表格列還可以自定義。表格的行包含了查詢邏輯的執行順序和各個步驟信息。
執行計劃表格內容的執行順序是：按照從左至右，從上至下的步驟執行，具體是指執行計劃按照層次逐步縮進，從左至右看，縮進最多的那一步最先執行，如果縮進量相同，則按照從上而下的方法判斷執行順序。
通過查看執行計劃表格的cost列，即成本花費能夠知道哪個步驟花費的成本高，通過查看執行計劃表格的行中的objectname列，能夠知道是否使用到表中的索引。
步驟閱讀
6
本文先簡單介紹在plsql中的使用方法，後續會逐步完成各種理論和技巧的使用方法，例如優化器、表連接訪問方法、索引等
Ⅲ 獲取SQL執行計劃的常見幾種方法
1. 預估執行計劃 - Explain Plan
Explain plan以SQL語句作為輸入，得到這條SQL語句的執行計劃，並將執行計劃輸出存儲到計劃表中。
首先，在你要執行的SQL語句前加explain plan for，此時將生成的執行計劃存儲到計劃表中，語句如下：
explain plan for SQL語句
然後，在計劃表中查詢剛剛生成的執行計劃，語句如下：
select * from table(dbms_xplan.display);
注意：Explain plan只生成執行計劃，並不會真正執行SQL語句，因此產生的執行計劃有可能不準，因為：
1）當前的環境可能和執行計劃生成時的環境不同；
2）不會考慮綁定變數的數據類型；
3）不進行變數窺視。
2. 查詢內存中緩存的執行計劃 （dbms_xplan.display_cursor）
如果你想獲取正在執行的或剛執行結束的SQL語句真實的執行計劃（即獲取library cache中的執行計劃），可以到動態性能視圖里查詢。方法如下：
1）獲取SQL語句的游標
游標分為父游標和子游標，父游標由sql_id(或聯合address和hash_value)欄位表示，子游標由child_number欄位表示。
如果SQL語句正在運行，可以從v$session中獲得它的游標信息，如：
select status, sql_id, sql_child_number from v$session where status='ACTIVE' and ....
如果知道SQL語句包含某些關鍵字，可以從v$sql視圖中獲得它的游標信息，如：
select sql_id, child_number, sql_text from v$sql where sql_text like '%關鍵字%『
2）獲取庫緩存中的執行計劃
為了獲取緩存庫中的執行計劃，可以直接查詢動態性能視圖v$sql_plan和v$sql_plan_statistics_all等，但更方便的方法是以sql_id和子游標為參數，執行如下語句：
select * from table(dbms_xplan.display_cursor('sql_id',child_number));
3）獲取前一次的執行計劃：
set serveroutput off
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
3. 查詢歷史執行計劃（dbms_xplan.display_awr）
AWR會定時把動態性能視圖中的執行計劃保存到dba_hist_sql_plan視圖中，如果你想要查看歷史執行計劃，可以採用如下方法查詢：
select * from table(dbms_xplan.display_awr('sql_id');
4. 在用sqlplus做SQL開發是（Autotrace）
set autotrace是sqlplus工具的一個功能，只能在通過sqlplus連接的session中使用，它非常適合在開發時測試SQL語句的性能，有以下幾種參數可供選擇：
SET AUTOTRACE OFF ---------------- 不顯示執行計劃和統計信息，這是預設模式
SET AUTOTRACE ON EXPLAIN ------ 只顯示優化器執行計劃
SET AUTOTRACE ON STATISTICS -- 只顯示統計信息
SET AUTOTRACE ON ----------------- 執行計劃和統計信息同時顯示
SET AUTOTRACE TRACEONLY ------ 不真正執行，只顯示預期的執行計劃，同explain plan
5. 生成Trace文件查詢詳細的執行計劃 （SQL_Trace, 10046）
SQL_TRACE作為初始化參數可以在實例級別啟用，也可以只在會話級別啟用，在實例級別啟用SQL_TRACE會導致所有進程的活動被跟蹤，包括後台進程及所有用戶進程，這通常會導致比較嚴重的性能問題，所以在一般情況下，我們使用sql_trace跟蹤當前進程，方法如下：
SQL>alter session set sql_trace=true;
...被跟蹤的SQL語句...
SQL>alter session set sql_trace=false;
如果要跟蹤其它進程，可以通過Oracle提供的系統包DBMS_SYSTEM. SET_SQL_TRACE_IN_SESSION來實現，例如：
SQL> exec dbms_system.set_sql_trace_in_session(sid,serial#,true) --開始跟蹤
SQL> exec dbms_system.set_sql_trace_in_session(sid,serial#,false) --結束跟蹤
生成trace文件後，再用tkprof 工具將sql trace 生成的跟蹤文件轉換成易讀的格式，語法如下：
tkprof inputfile outputfile
10046事件是SQL_TRACE的一個升級版，它也是追蹤會話，生成Trace文件，只是它裡面的內容更詳細，
Ⅳ SQL執行與優化
SQL優化
執行計劃,表關聯查詢順序,優化策略與思路
下面再向前走一些，容我根據自己的認識說一下查詢執行的流程是怎樣的：
1.連接
1.1客戶端發起一條Query請求，監聽客戶端的『連接管理模塊』接收請求
1.2將請求轉發到『連接進/線程模塊』
1.3調用『用戶模塊』來進行授權檢查
1.4通過檢查後，『連接進/線程模塊』從『線程連接池』中取出空閑的被緩存的連接線程和客戶端請求對接，如果失敗則創建一個新的連接請求
2.處理
2.1先查詢緩存，檢查Query語句是否完全匹配，接著再檢查是否具有許可權，都成功則直接取數據返回
2.2上一步有失敗則轉交給『命令解析器』，經過詞法分析，語法分析後生成解析樹
2.3接下來是預處理階段，處理解析器無法解決的語義，檢查許可權等，生成新的解析樹
2.4再轉交給對應的模塊處理
2.5如果是SELECT查詢還會經由『查詢優化器』做大量的優化，生成執行計劃
2.6模塊收到請求後，通過『訪問控制模塊』檢查所連接的用戶是否有訪問目標表和目標欄位的許可權
2.7有則調用『表管理模塊』，先是查看table cache中是否存在，有則直接對應的表和獲取鎖，否則重新打開表文件
2.8根據表的meta數據，獲取表的存儲引擎類型等信息，通過介面調用對應的存儲引擎處理
2.9上述過程中產生數據變化的時候，若打開日誌功能，則會記錄到相應二進制日誌文件中
3.結果
3.1Query請求完成後，將結果集返回給『連接進/線程模塊』
3.2返回的也可以是相應的狀態標識，如成功或失敗等
3.3『連接進/線程模塊』進行後續的清理工作，並繼續等待請求或斷開與客戶端的連接
接下來再走一步，讓我們看看一條SQL語句的前世今生。
首先看一下示例語句
示例語句
執行順序
SQL解析
1. FROM
當涉及多個表的時候，左邊表的輸出會作為右邊表的輸入，之後會生成一個虛擬表VT1。
(1-J1)笛卡爾積
計算兩個相關聯表的笛卡爾積(CROSS JOIN) ，生成虛擬表VT1-J1。
兩次全表掃描
哈希索引,查找復雜度都是 O(1) 。
2. WHERE
對VT1過程中生成的臨時表進行過濾，滿足WHERE子句的列被插入到VT2表中。
注意：
此時因為分組，不能使用聚合運算；也不能使用SELECT中創建的別名；
與ON的區別：
如果有外部列，ON針對過濾的是關聯表，主表（保留表）會返回所有的列；
如果沒有添加外部列，兩者的效果是一樣的；
應用：
對主表的過濾應該放在WHERE；
對於關聯表，先條件查詢後連接則用ON，先連接後條件查詢則用WHERE；
hash join 哈希連接 驅動表和被驅動表都只會訪問0次或1次
應用場景:一個大表一個小表/表上沒有索引/返回結果集比較大
3. GROUP BY
這個子句會把VT2中生成的表按照GROUP BY中的列進行分組。生成VT3表。
注意：
其後處理過程的語句，如SELECT,HAVING，所用到的列必須包含在GROUP BY中，對於沒有出現的，得用聚合函數；
原因：
GROUP BY改變了對表的引用，將其轉換為新的引用方式，能夠對其進行下一級邏輯操作的列會減少；
原作者的理解是：
根據分組欄位，將具有相同分組欄位的記錄歸並成一條記錄，因為每一個分組只能返回一條記錄，除非是被過濾掉了，而不在分組欄位裡面的欄位可能會有多個值，多個值是無法放進一條記錄的，所以必須通過聚合函數將這些具有多值的列轉換成單值；
GROUP BY 重新聚合查詢
4. HAVING
這個子句對VT3表中的不同的組進行過濾，只作用於分組後的數據，滿足HAVING條件的子句被加入到VT4表中。
7.LIMIT
LIMIT子句從上一步得到的VT6虛擬表中選出從指定位置開始的指定行數據。
注意：
offset和rows的正負帶來的影響；
當偏移量很大時效率是很低的，可以這么做：
採用子查詢的方式優化，在子查詢里先從索引獲取到最大id，然後倒序排，再取N行結果集
採用INNER JOIN優化，JOIN子句里也優先從索引獲取ID列表，然後直接關聯查詢獲得最終結果
當前未用到索引,
三次full scan , table1 AS a / table2 AS b / GROUP BY
盡量少做重復的工作
控制同一語句的多次執/減少多次的數據轉換/
杜絕不必要的子查詢和連接表，子查詢在執行計劃一般解釋成外連接，多餘的連接表帶來額外的開銷
關於臨時表和表變數的選擇
臨時表產生使用SELECT INTO和CREATE TABLE + INSERT INTO的選擇，一般情況下，SELECT INTO會比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO會鎖定TEMPDB的系統表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用戶並發環境下，容易阻塞其他進程，所以建議，在並發系統中，盡量使用CREATE TABLE + INSERT INTO，而大數據量的單個語句使用中，使用SELECT INTO。
子查詢的用法
相關子查詢可以用IN、NOT IN、EXISTS、NOT EXISTS引入
NOT IN、NOT EXISTS的相關子查詢可以改用LEFT JOIN代替寫法
如果保證子查詢沒有重復 ，IN、EXISTS的相關子查詢可以用INNER JOIN 代替
IN``的相關子查詢用EXISTS代替
不要用 COUNT (*)的子查詢判斷是否存在記錄，最好用 LEFT` `JOIN 或者EXISTS，比如有人寫這樣的語句：
建立索引後，並不是每個查詢都會使用索引，在使用索引的情況下，索引的使用效率也會有很大的差別。只要我們在查詢語句中沒有強制指定索引，
不要對索引欄位進行運算，而要想辦法做變換
不要對索引欄位進行格式轉換
不要對索引欄位使用函數
不要對索引欄位進行多欄位連接
join關聯查詢的計算是很復雜的，特別是數據量比較大的情況下，實際情況還是拆解較快的
Join拆解的核心就是利用In關鍵字
要麼用空間換時間，要麼用時間換空間
多表連接的連接條件對索引的選擇有著重要的意義，所以我們在寫連接條件條件的時候需要特別注意。
A、多表連接的時候，連接條件必須寫全，寧可重復，不要缺漏。
B、連接條件盡量使用聚集索引
C、注意ON、WHERE和HAVING部分條件的區別
ON是最先執行， WHERE次之，HAVING最後，因為ON是先把不符合條件的記錄過濾後才進行統計，它就可以減少中間運算要處理的數據，按理說應該速度是最快的，WHERE也應該比 HAVING快點的，因為它過濾數據後才進行SUM，在兩個表聯接時才用ON的，所以在一個表的時候，就剩下WHERE跟HAVING比較了
考慮聯接優先順序：
(1)INNER JOIN
(2)LEFT JOIN (註：RIGHT JOIN 用 LEFT JOIN 替代)
(3)CROSS JOIN
索引並不適用於所有情況：a.少量數據；b.頻繁進行改動的欄位，不適合做索引；c.很少使用的欄位，不需要加索引
索引會提高數據查詢效率，但是會降低「增、刪、改」的效率。當不使用索引的時候，我們進行數據的增刪改，只需要操作源表即可，但是當我們添加索引後，不僅需要修改源表，也需要再次修改索引，很麻煩。
先執行順序, 是否走索引, 有無類型轉換
18000 字的SQL優化大全
步步深入：MySQL架構總覽->查詢執行流程->SQL解析順序
MySQL索引總結（4）——btree與hash區別
Ⅳ 怎麼分析sql語句的執行計劃的步驟
SQL 語句摘要可以用在MySQL的各個方面，比如 性能字典里對語句的分析，查詢重寫插件規則改寫等等。
接下來依次看下語句摘要在這兩方面的使用。
1. 性能字典
mysql> call sys.ps_setup_enable_consumer('statements');
+---------------------+
| summary |
+---------------------+
| Enabled 4 consumers |
+---------------------+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
開啟後，執行幾次之前的幾條 SQL。
完後可以很方便的從 sys 庫里分析這類語句的執行情況，包括執行次數，執行時間，掃描的記錄數，鎖定的時間，是否用到排序等等。
2. 查詢重寫插件
比如要阻止對表 p1 通過欄位 r1 的刪除動作，可以用查詢重寫插件在 MySQL 語句分析層直接轉換，這時候就得用到摘要函數 statement_digest_text。
假設：表 p1 欄位 id 值全部為正。
delete from p1 where id = 1000;
要改寫為，
delete from p1 where id = -1;
利用函數 statement_digest_text 來定製這條 SQL 的重寫規則。
mysql> INSERT INTO query_rewrite.rewrite_rules (pattern, replacement,pattern_database) -> VALUES( -> statement_digest_text('delete from p1 where id = 1000') , -> statement_digest_text('delete from p1 where id = -1'), -> 'ytt' -> );Query OK, 1 row affected (0.01 sec)
語句被查詢重寫後的效果：
mysql> delete from p1 where id = 20000;Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> show warnings\G*************************** 1. row *************************** Level: Note Code: 1105Message: Query 'delete from p1 where id = 20000' rewritten to 'DELETE FROM `p1` WHERE `id` = - 20000' by a query rewrite plugin1 row in set (0.00 sec)mysql> select count(*) from p1;+----------+| count(*) |+----------+| 9000001 |+----------+1 row in set (1.59 sec)
總結
MySQL 8.0 新增的語句摘要函數可以很方便的分析 SQL 語句執行的各個方面，比以前分析類似的場景要簡單的多。
Ⅵ sql執行計劃怎麼看
打開PL/SQL Developer軟體，請確保plsql能夠成功連接到一個oracle資料庫。
在PL/SQL Developer中寫好一段SQL代碼，按F5，或者點擊「執行執行計劃」圖標，PL/SQL Developer會自動打開執行計劃窗口，顯示該SQL的執行計劃。
可以看到窗口上方是sql語句，下方顯示執行計劃表格。表格的列主要包含描述、用戶、對象、成本花費、IO開銷等，表格，當然表格列還可以自定義。表格的行包含了查詢邏輯的執行順序和各個步驟信息。
執行計劃表格內容的執行順序是：按照從左至右，從上至下的步驟執行，具體是指執行計劃按照層次逐步縮進，從左至右看，縮進最多的那一步最先執行，如果縮進量相同，則按照從上而下的方法判斷執行順序。
通過查看執行計劃表格的cost列，即成本花費能夠知道哪個步驟花費的成本高，通過查看執行計劃表格的行中的objectname列，能夠知道是否使用到表中的索引。
Ⅶ plsql怎麼查看sql執行計劃
打開PL/SQL Developer軟體，請確保plsql能夠成功連接到一個oracle資料庫。
通過查看執行計劃表格的cost列，即成本花費能夠知道哪個步驟花費的成本高，通過查看執行計劃表格的行中的objectname列，能夠知道是否使用到表中的索引。
Ⅷ 通過分析SQL語句的執行計劃優化SQL
如何干預執行計劃
-
-
使用hints提示
基於代價的優化器是很聰明的，在絕大多數情況下它會選擇正確的優化器，減輕了DBA的負擔。但有時它也聰明反被聰明誤，選擇了很差的執行計劃，使某個語句的執行變得奇慢無比。此時就需要DBA進行人為的干預，告訴優化器使用我們指定的存取路徑或連接類型生成執行計劃，從而使語句高效的運行。例如，如果我們認為對於一個特定的語句，執行全表掃描要比執行索引掃描更有效，則我們就可以指示優化器使用全表掃描。在Oracle中，是通過為語句添加hints(提示)來實現干預優化器優化的目的。
hints是oracle提供的一種機制，用來告訴優化器按照我們的告訴它的方式生成執行計劃。我們可以用hints來實現：
1.
使用的優化器的類型
2.基於代價的優化器的優化目標，是all_rows還是first_rows。
3.
表的訪問路徑，是全表掃描，還是索引掃描，還是直接利用rowid。
4.
表之間的連接類型
5.
表之間的連接順序
6.
語句的並行程度
除了」RULE」提示外，一旦使用的別的提示，語句就會自動的改為使用CBO優化器，此時如果你的數據字典中沒有統計數據，就會使用預設的統計數據。所以建議大家如果使用CBO或HINTS提示，則最好對表和索引進行定期的分析。
如何使用hints:
Hints只應用在它們所在sql語句塊(statement
block，由select、update、delete關鍵字標識)上，對其它SQL語句或語句的其它部分沒有影響。如：對於使用union操作的2個sql語句，如果只在一個sql語句上有hints，則該hints不會影響另一個sql語句。
我們可以使用注釋(comment)來為一個語句添加hints，一個語句塊只能有一個注釋，而且注釋只能放在SELECT,
UPDATE,
or
DELETE關鍵字的後面
使用hints的語法：
{DELETE|INSERT|SELECT|UPDATE}
/*+
hint
[text]
[hint[text]]...
*/
or
{DELETE|INSERT|SELECT|UPDATE}
--+
hint
[text]
[hint[text]]...
註解：
1.DELETE、INSERT、SELECT和UPDATE是標識一個語句塊開始的關鍵字，包含提示的注釋只能出現在這些關鍵字的後面，否則提示無效。
2.「+」號表示該注釋是一個hints，該加號必須立即跟在」/*」的後面，中間不能有空格。
3.hint是下面介紹的具體提示之一，如果包含多個提示，則每個提示之間需要用一個或多個空格隔開。
4.text
是其它說明hint的注釋性文本
如果你沒有正確的指定hints，Oracle將忽略該hints，並且不會給出任何錯誤。
Ⅸ oracle的執行計劃中表的鏈接方式有幾種分別適用什麼情況
在日常基於資料庫應用的開發過程中，我們經常需要對多個表或者數據源進行關聯查詢而得出我們需要的結果集。那麼Oracle到底存在著哪幾種連接方式？優化器內部又是怎樣處理這些連接的？哪種連接方式又是適合哪種查詢需求的？只有對這些問題有了清晰的理解後，我們才能針對特定的查詢需求選擇合適的連接方式，開發出健壯的資料庫應用程序。選擇合適的表連接方法對SQL語句運行的性能有著至關重要的影響。下面我們就Oracle常用的一些連接方法及適用情景做一個簡單的介紹。
3.1 嵌套循環連接(nested loop)
嵌套循環連接的工作方式是這樣的：
1、 Oracle首先選擇一張表作為連接的驅動表，這張表也稱為外部表（Outer Table）。由驅動表進行驅動連接的表或數據源稱為內部表（Inner Table）。
2、 提取驅動表中符合條件的記錄，與被驅動表的連接列進行關聯查詢符合條件的記錄。在這個過程中，Oracle首先提取驅動表中符合條件的第一條記錄，再與內部表的連接列進行關聯查詢相應的記錄行。在關聯查詢的過程中，Oracle會持續提取驅動表中其他符合條件的記錄與內部表關聯查詢。這兩個過程是並行進行的，因此嵌套循環連接返回前幾條記錄的速度是非常快的。在這里需要說明的是，由於Oracle最小的IO單位為單個數據塊，因此在這個過程中Oracle會首先提取驅動表中符合條件的單個數據塊中的所有行，再與內部表進行關聯連接查詢的，然後提取下一個數據塊中的記錄持續地循環連接下去。當然，如果單行記錄跨越多個數據塊的話，就是一次單條記錄進行關聯查詢的。
3、 嵌套循環連接的過程如下所示：
Nested loop
Outer loop
Inner loop
我們可以看出這裡面存在著兩個循環，一個是外部循環，提取驅動表中符合條件的每條記錄。另外一個是內部循環，根據外循環中提取的每條記錄對內部表進行連接查詢相應的記錄。由於這兩個循環是嵌套進行的，故此種連接方法稱為嵌套循環連接。
嵌套循環連接適用於查詢的選擇性強、約束性高並且僅返回小部分記錄的結果集。通常要求驅動表的記錄（符合條件的記錄，通常通過高效的索引訪問）較少，且被驅動表連接列有唯一索引或者選擇性強的非唯一索引時，嵌套循環連接的效率是比較高的。
嵌套循環連接驅動表的選擇也是連接中需要著重注意的一點，有一個常見的誤區是驅動表要選擇小表，其實這是不對的。假如有兩張表A、B關聯查詢，A表有1000000條記錄，B表有10000條記錄，但是A表過濾出來的記錄只有10條，這時候顯然用A表當做驅動表是比較合適的。因此驅動表是由過濾條件限制返回記錄最少的那張表，而不是根據表的大小來選擇的。
在外連接查詢中，如果走嵌套循環連接的話，那麼驅動表必然是沒有符合條件關聯的那張表，也就是後面不加(+)的那張表。這是由於外連接需要提取可能另一張表沒符合條件的記錄，因此驅動表需要是那張我們要返回所有符合條件記錄的表。比如下面這個查詢，
嵌套循環連接返回前幾行的記錄是非常快的，這是因為使用了嵌套循環後，不需要等到全部循環結束再返回結果集，而是不斷地將查詢出來的結果集返回。在這種情況下，終端用戶將會快速地得到返回的首批記錄，且同時等待Oracle內部處理其他記錄並返回。如果查詢的驅動表的記錄數非常多，或者被驅動表的連接列上無索引或索引不是高度可選的情況，嵌套循環連接的效率是非常低的
-- 刪除原表
drop table t1;
-- 建立測試表
create table t1(
f1 varchar2(10),
f2 varchar2(1000)
)
tablespace CTL
pctfree 98;
-- 填充測試內容
insert into t1(f1,f2)
select rownum, lpad(rownum,700,'0')
from dba_tables a, dba_tab_cols b
where a.owner = b.owner
and rownum < 10000;
commit;
-- 檢查測試內容格式
select sys.dbms_rowid.rowid_block_number(rowid), f1, f2 from t1;
-- 每條記錄都存儲在單獨的數據塊中
select count( distinct sys.dbms_rowid.rowid_block_number(rowid)) from t1;
/*
用同樣的方式建立表t2
*/
-- 刪除原表
drop table t2;
-- 建立測試表
create table t2(
f1 varchar2(10),
f2 varchar2(1000)
)
tablespace CTL
pctfree 98;
-- 填充測試內容
insert into t2(f1,f2)
select rownum * 10, lpad(rownum * 10,700,'0')
from dba_tables a, dba_tab_cols b
where a.owner = b.owner
and rownum < 1000;
commit;
-- 檢查測試內容格式
select sys.dbms_rowid.rowid_block_number(rowid), f1, f2 from t2;
-- 每條記錄都存儲在單獨的數據塊中
select count( distinct sys.dbms_rowid.rowid_block_number(rowid)) from t2;
create index ind_t1_f1 on t1(f1);
create index ind_t2_f1 on t2(f1);
--首先我們來看使用nested loop關聯方式, 不同表作為驅動時的情況.
1, 表t2作為驅動表
select /*+ ordered use_nl(t1 , t2)*/
t1.f1, t2.f1
from ctl.t2 t2,ctl.t1 t1
where t1.f1 = t2.f1
and t1.f1 < 1000;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=84 Card=4 Bytes=56)
1 0 NESTED LOOPS (Cost=84 Card=4 Bytes=56)
2 1 TABLE ACCESS (FULL) OF 'T2' (Cost=2 Card=82 Bytes=574)
3 1 INDEX (RANGE SCAN) OF 'IND_T1_F1' (NON-UNIQUE) (Cost=1 C
ard=1 Bytes=7)
Cost = outer access cost + (inner access cost * outer cardinality)
Cost = 2 + 1 * 82 = 84;
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2020 consistent gets
23 physical reads
0 redo size
2650 bytes sent via SQL*Net to client
721 bytes received via SQL*Net from client
8 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
99 rows processed
2, t1作為驅動表
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=4 Bytes=56)
1 0 NESTED LOOPS (Cost=6 Card=4 Bytes=56)
2 1 TABLE ACCESS (FULL) OF 'T1' (Cost=2 Card=4 Bytes=28)
3 1 INDEX (RANGE SCAN) OF 'IND_T2_F1' (NON-UNIQUE) (Cost=1 C
ard=1 Bytes=7)
Cost = outer access cost + (inner access cost * outer cardinality)
Cost = 2 + 1 * 4 = 84;
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
11123 consistent gets
3 physical reads
0 redo size
2650 bytes sent via SQL*Net to client
721 bytes received via SQL*Net from client
8 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
99 rows processed
3.2, 哈希連接(hash join)
哈希連接分為兩個階段，如下。
1、 構建階段：優化器首先選擇一張小表做為驅動表，運用哈希函數對連接列進行計算產生一張哈希表。通常這個步驟是在內存（hash_area_size）裡面進行的，因此運算很快。
2、 探測階段：優化器對被驅動表的連接列運用同樣的哈希函數計算得到的結果與前面形成的哈希表進行探測返回符合條件的記錄。這個階段中如果被驅動表的連接列的值沒有與驅動表連接列的值相等的話，那麼這些記錄將會被丟棄而不進行探測
哈希連接比較適用於返回大數據量結果集的連接。
使用哈希連接必須是在CBO模式下，參數hash_join_enabled設置為true，
哈希連接只適用於等值連接。從Oracle9i開始，哈希連接由於其良好的性能漸漸取代了原來的排序合並連接。
SQL> select /*+ ordered use_hash(t1 , t2) */
t1.f1, t2.f1
from ctl.t1 t1,ctl.t2 t2
where t1.f1 = t2.f1 2 3 4 ;
999 rows selected.
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=5 Card=82 Bytes=1148
)
1 0 HASH JOIN (Cost=5 Card=82 Bytes=1148)
2 1 TABLE ACCESS (FULL) OF 'T1' (Cost=2 Card=82 Bytes=574)
3 1 TABLE ACCESS (FULL) OF 'T2' (Cost=2 Card=82 Bytes=574)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
11113 consistent gets
0 physical reads
0 redo size
23590 bytes sent via SQL*Net to client
1381 bytes received via SQL*Net from client
68 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
999 rows processed
3.3, 排序合並連接(merge join)
排序合並連接的方法非常簡單。在排序合並連接中是沒有驅動表的概念的，兩個互相連接的表按連接列的值先排序，排序完後形成的結果集再互相進行合並連接提取符合條件的記錄。相比嵌套循環連接，排序合並連接比較適用於返回大數據量的結果。
排序合並連接在數據表預先排序好的情況下效率是非常高的，也比較適用於非等值連接的情況，比如>、>=、<=等情況下的連接（哈希連接只適用於等值連接）。由於Oracle中排序操作的開銷是非常消耗資源的，當結果集很大時排序合並連接的性能很差，於是Oracle在7.3之後推出了新的連接方式——哈希連接。
1, rbo模式;
2, 不等於關聯(> < >= <= <>)
3, hash_join_enabled = false;
4, 數據源已排序