| 導購 | 订阅 | 在线投稿
分享
 
 
 

Oracle認證:何時使用綁定變量性能反而差

來源:互聯網網民  2008-05-31 00:48:02  評論

掃描成本和OPTIMIZER_INDEX_COST_ADJ

我們知道,在CBO模式下,Oracle會計算各個訪問路徑的代價,采用最小代價的訪問路徑作爲語句的執行計劃。而對于索引的訪問代價的計算,需要根據一個系統參數OPTIMIZER_INDEX_COST_ADJ來轉換爲與全表掃描代價等價的一個值。這是什麽意思呢?我們先稍微解釋一下這個參數:OPTIMIZER_INDEX_COST_ADJ。它的值是一個百分比,默認是100,取值範圍是1~10000。當估算索引掃描代價時,會將索引的原始代價值乘以這個百分比,將換算後的值作爲與全表掃描代價比較的值。也就是說,當這個值爲100時,計算出的索引掃描代價就是它的原始代價: COST_COM = COST_ORG * OPTIMIZER_INDEX_COST_ADJ/100

看以下例子:

以下是引用片段:

SQL> create table T_PEEKING (a NUMBER, b char(1), c char(2000));

Table created.

SQL>

SQL> create index T_PEEKING_IDX1 on T_PEEKING(b);

Index created.

SQL> begin

2 for i in 1..1000 loop

3 insert into T_PEEKING values (i, 'A', i);

4 end loop;

5

6 insert into T_PEEKING values (1001, 'B', 1001);

7 insert into T_PEEKING values (1002, 'B', 1002);

8 insert into T_PEEKING values (1003, 'C', 1003);

9

10 commit;

11 end;

12 /

PL/SQL procedure successfully completed.

注意,我們給索引字段B插入的值中只有3個distinct值,記錄數是1003,它的集的勢很高(1003/3)=334。

以下是引用片段:

SQL>

SQL> analyze table T_PEEKING compute

statistics for table for all indexes for all indexed columns;

Table analyzed.

SQL>

我們看下索引掃描的代價是多少: SQL> show parameter OPTIMIZER_INDEX_COST_ADJ

以下是引用片段:

NAME TYPE VALUE

------------------------------------ ----------- ------

optimizer_index_cost_adj integer 100

SQL> delete from plan_table;

0 rows deleted.

SQL>

SQL> explain plan for select

/*+index(a T_PEEKING_IDX1)*/ * from T_PEEKING a where b = :V;

Explained.

SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||

2 object_name||' '||decode(id, 0, 'Cost='||position) "Query

3 Plan_Table"

4 from plan_table

5 start with id = 0

6 connect by prior id = parent_id

7 ;

Query

Plan_Table

-----------------------------------------------------

SELECT STATEMENT Cost=113

TABLE ACCESS BY INDEX ROWID T_PEEKING

INDEX RANGE SCAN T_PEEKING_IDX1

SQL>

再看全表掃描的代價是多少: 以下是引用片段:

SQL> delete from plan_table;

3 rows deleted.

SQL>

SQL> explain plan for select

/*+full(a)*/ * from T_PEEKING a where b = :V;

Explained.

SQL>

SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||

2 object_name||' '||decode(id, 0, 'Cost='||position) "Query

3 Plan_Table"

4 from plan_table

5 start with id = 0

6 connect by prior id = parent_id

7 ;

Query

Plan_Table

----------------------------------------------------

SELECT STATEMENT Cost=75

TABLE ACCESS FULL T_PEEKING

SQL>

這時,我們可以計算得出讓優化器使用索引(無提示強制)的OPTIMIZER_INDEX_COST_ADJ值應該< ROUND(COST_FTS/COST_IDX*100) = ROUND(75/113*100) = 66,而大于66則會使用全表掃描: SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=67;

以下是引用片段:

System altered.

SQL>

SQL> delete from plan_table;

2 rows deleted.

SQL>

SQL> explain plan for select * from T_PEEKING a where b = :V;

Explained.

SQL>

SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||

2 object_name||' '||decode(id, 0, 'Cost='||position) "Query

3 Plan_Table"

4 from plan_table

5 start with id = 0

6 connect by prior id = parent_id;

Query

Plan_Table

-----------------------------------------------------------------

SELECT STATEMENT Cost=75

TABLE ACCESS FULL T_PEEKING

SQL>

SQL>

SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=66;

System altered.

SQL>

SQL> delete from plan_table;

2 rows deleted.

SQL>

SQL> explain plan for select * from T_PEEKING a where b = :V;

Explained.

SQL>

SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||

2 object_name||' '||decode(id, 0, 'Cost='||position) "Query

3 Plan_Table"

4 from plan_table

5 start with id = 0

6 connect by prior id = parent_id;

Query

Plan_Table

---------------------------------------------------------

SELECT STATEMENT Cost=75

TABLE ACCESS BY INDEX ROWID T_PEEKING

INDEX RANGE SCAN T_PEEKING_IDX1

可以看出,在使用綁定變量時,參數OPTIMIZER_INDEX_COST_ADJ對于是否選擇索引會有重要的影響。

這裏我們暫且不討論索引掃描的原始成本是如何計算得出的。但是有一點很重要,在使用綁定變量時,計算出的成本是平均成本。在我們上面的例子中,字段B的值只有3個:"A"、"B"、"C",其中A最多,1003行中有1000行。因此,在索引上掃描值爲A記錄的成本爲1000/1003 * 索引全掃描成本 ≈索引全掃描成本,我們看下它的成本是多少:

以下是引用片段:

SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=100;

System altered.

SQL>

SQL> delete from plan_table;

2 rows deleted.

SQL>

SQL> explain plan for select

/*+index(a T_PEEKING_IDX1)*/* from T_PEEKING a where b = 'A';

Explained.

SQL>

SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||

2 object_name||' '||decode(id, 0, 'Cost='||position) "Query

3 Plan_Table"

4 from plan_table

5 start with id = 0

6 connect by prior id = parent_id;

Query

Plan_Table

--------------------------------------------------------------

SELECT STATEMENT Cost=336

TABLE ACCESS BY INDEX ROWID T_PEEKING

INDEX RANGE SCAN T_PEEKING_IDX1

可以看到,它的成本是336。因此索引的平均成本是(336 * 1003/1000) / 3 ≈ 113,也就是使用綁定變量使的成本。而掃描其它兩個值"B"和"A"時代價就非常小。 以下是引用片段:

SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=100;

System altered.

SQL>

SQL> delete from plan_table;

3 rows deleted.

SQL>

SQL> explain plan for select

/*+index(a T_PEEKING_IDX1)*/* from T_PEEKING a where b = 'B';

Explained.

SQL>

SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||

2 object_name||' '||decode(id, 0, 'Cost='||position) "Query

3 Plan_Table"

4 from plan_table

5 start with id = 0

6 connect by prior id = parent_id;

Query

Plan_Table

---------------------------------------------------------------

SELECT STATEMENT Cost=2

TABLE ACCESS BY INDEX ROWID T_PEEKING

INDEX RANGE SCAN T_PEEKING_IDX1

因爲計算的成本是平均成本(相對實際掃描某個值的成本,平均成本更接近全表掃描成本),因此在創建查詢計劃時,使用綁定變量將更加容易受到參數OPTIMIZER_INDEX_COST_ADJ影響,特別是上面的這種情況(即索引字段的集的勢非常高時)下,平均代價與實際掃描某個值代價相差非常遠。這種情況下,OPTIMIZER_INDEX_COST_ADJ對不使用綁定變量查詢影響就非常小(因爲索引代價不是比全表掃描成本大很多就是小很多),不管掃描哪個值,不使用綁定變量將更加容易選擇到合理的查詢計劃。

綁定變量窺視

在了解了參數OPTIMIZER_INDEX_COST_ADJ的作用後。再了解一個對查詢計劃,特別是使用綁定變量時會産生重大影響的特性:綁定變量窺視(Bind Variables Peeking)。

綁定變量窺視是9i以後的一個新特性。它使CBO優化器在計算訪問代價時,將綁定變量傳入的值考慮進去,從而計算出更合理的成本(否則,將會計算平均成本)。看下面例子: 以下是引用片段:

SQL> conn sys/sys as sysdba

Connected.

SQL>

SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=60;

System altered.

SQL> analyze table T_PEEKING compute

statistics for table for all indexes for all indexed columns;

Table analyzed.

SQL>

SQL> set autot trace

SQL>

SQL> alter session set sql_trace = true;

Session altered.

SQL>

SQL> var v char(1)

SQL>

SQL> exec :v := 'A';

PL/SQL procedure successfully completed.

SQL>

SQL> select * from T_PEEKING a where b = :V;

1000 rows selected.

SQL>

SQL> alter session set sql_trace = false;

Session altered.

用Tkprof處理生成的trace文件。因爲在存在綁定變量窺視時,autotrace或者explain plan可能不會顯示正確的查詢計劃,需要Tkprof來處理sql trace。 tkprof fuyuncat_ora_5352.trc aaa.txt

此時OPTIMIZER_INDEX_COST_ADJ是60,根據上面的結論,似乎查詢計劃應該選擇掃描索引。但是,這裏給綁定變量賦了值"A",這時,優化器會「窺視」到這個值,並且在計算掃描成本時按照這個值的成本來計算。因此,得出的查詢計劃是全表掃描,而不是掃描索引,靠Tkprof分析的結果: 以下是引用片段:

select * from T_PEEKING a where b = :V

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.00 0.00 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 68 0.01 0.07 0 406 0 1000

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 70 0.01 0.08 0 406 0 1000

Misses in library cache during parse: 1

Optimizer mode: CHOOSE

Parsing user id: SYS

Rows Row Source Operation

------- ---------------------------------------------------

1000 TABLE ACCESS FULL T_PEEKING (cr=406 pr=0 pw=0 time=5052 us)

但是,綁定變量窺視對一條語句只會使用一次。就是說,在第一次解析語句時,將綁定變量值考慮進去計算成本生成查詢計劃。以後在執行該語句時都采用這個查詢計劃,而不再考慮以後綁定變量的值是什麽了。 SQL> conn sys/sys as sysdba

以下是引用片段:

Connected.

SQL>

SQL>

SQL> set autot trace

SQL>

SQL> alter session set sql_trace = true;

Session altered.

SQL>

SQL> var v char(1)

SQL>

SQL> exec :v := 'B';

PL/SQL procedure successfully completed.

SQL>

SQL> select * from T_PEEKING a where b = :V;

1000 rows selected.

SQL>

SQL> alter session set sql_trace = false;

Session altered.

再用Tkprof分析生成的trace文件,看到盡管這裏的值是"B",選擇索引掃描會更優,但分析結果中查詢計劃還是使用全表掃描: select *

以下是引用片段:

from

T_PEEKING a where b = :V

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.00 0.00 0 0 0 0

Execute 1 0.00 0.00 0 0 0 0

Fetch 2 0.00 0.00 0 340 0 2

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 4 0.00 0.00 0 340 0 2

Misses in library cache during parse: 0

Optimizer mode: CHOOSE

Parsing user id: SYS

Rows Row Source Operation

------- ---------------------------------------------------

2 TABLE ACCESS FULL T_PEEKING (cr=340 pr=0 pw=0 time=1005 us)

因此,這種情況下使用綁定變量也會導致無法選擇最優的查詢計劃。

綜上所述,我們可以得出一個結論:在對建有索引的字段(包括字段集),且字段(集)的集的勢非常大時,使用綁定變量可能會導致查詢計劃錯誤,因而會使查詢效率非常低。

 
特别声明:以上内容(如有图片或视频亦包括在内)为网络用户发布,本站仅提供信息存储服务。
 
  掃描成本和OPTIMIZER_INDEX_COST_ADJ   我們知道,在CBO模式下,Oracle會計算各個訪問路徑的代價,采用最小代價的訪問路徑作爲語句的執行計劃。而對于索引的訪問代價的計算,需要根據一個系統參數OPTIMIZER_INDEX_COST_ADJ來轉換爲與全表掃描代價等價的一個值。這是什麽意思呢?我們先稍微解釋一下這個參數:OPTIMIZER_INDEX_COST_ADJ。它的值是一個百分比,默認是100,取值範圍是1~10000。當估算索引掃描代價時,會將索引的原始代價值乘以這個百分比,將換算後的值作爲與全表掃描代價比較的值。也就是說,當這個值爲100時,計算出的索引掃描代價就是它的原始代價: COST_COM = COST_ORG * OPTIMIZER_INDEX_COST_ADJ/100   看以下例子: 以下是引用片段:   SQL> create table T_PEEKING (a NUMBER, b char(1), c char(2000));   Table created.   SQL>   SQL> create index T_PEEKING_IDX1 on T_PEEKING(b);   Index created.   SQL> begin   2 for i in 1..1000 loop   3 insert into T_PEEKING values (i, 'A', i);   4 end loop;   5   6 insert into T_PEEKING values (1001, 'B', 1001);   7 insert into T_PEEKING values (1002, 'B', 1002);   8 insert into T_PEEKING values (1003, 'C', 1003);   9   10 commit;   11 end;   12 /   PL/SQL procedure successfully completed.   注意,我們給索引字段B插入的值中只有3個distinct值,記錄數是1003,它的集的勢很高(1003/3)=334。 以下是引用片段:   SQL>   SQL> analyze table T_PEEKING compute   statistics for table for all indexes for all indexed columns;   Table analyzed.   SQL>   我們看下索引掃描的代價是多少: SQL> show parameter OPTIMIZER_INDEX_COST_ADJ 以下是引用片段:   NAME TYPE VALUE   ------------------------------------ ----------- ------   optimizer_index_cost_adj integer 100   SQL> delete from plan_table;   0 rows deleted.   SQL>   SQL> explain plan for select   /*+index(a T_PEEKING_IDX1)*/ * from T_PEEKING a where b = :V;   Explained.   SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||   2 object_name||' '||decode(id, 0, 'Cost='||position) "Query   3 Plan_Table"   4 from plan_table   5 start with id = 0   6 connect by prior id = parent_id   7 ;   Query   Plan_Table   -----------------------------------------------------   SELECT STATEMENT Cost=113   TABLE ACCESS BY INDEX ROWID T_PEEKING   INDEX RANGE SCAN T_PEEKING_IDX1   SQL>   再看全表掃描的代價是多少: 以下是引用片段: SQL> delete from plan_table;   3 rows deleted.   SQL>   SQL> explain plan for select   /*+full(a)*/ * from T_PEEKING a where b = :V;   Explained.   SQL>   SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||   2 object_name||' '||decode(id, 0, 'Cost='||position) "Query   3 Plan_Table"   4 from plan_table   5 start with id = 0   6 connect by prior id = parent_id   7 ;   Query   Plan_Table   ----------------------------------------------------   SELECT STATEMENT Cost=75   TABLE ACCESS FULL T_PEEKING   SQL>   這時,我們可以計算得出讓優化器使用索引(無提示強制)的OPTIMIZER_INDEX_COST_ADJ值應該< ROUND(COST_FTS/COST_IDX*100) = ROUND(75/113*100) = 66,而大于66則會使用全表掃描: SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=67; 以下是引用片段:   System altered.   SQL>   SQL> delete from plan_table;   2 rows deleted.   SQL>   SQL> explain plan for select * from T_PEEKING a where b = :V;   Explained.   SQL>   SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||   2 object_name||' '||decode(id, 0, 'Cost='||position) "Query   3 Plan_Table"   4 from plan_table   5 start with id = 0   6 connect by prior id = parent_id;   Query   Plan_Table   -----------------------------------------------------------------   SELECT STATEMENT Cost=75   TABLE ACCESS FULL T_PEEKING   SQL>   SQL>   SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=66;   System altered.   SQL>   SQL> delete from plan_table;   2 rows deleted.   SQL>   SQL> explain plan for select * from T_PEEKING a where b = :V;   Explained.   SQL>   SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||   2 object_name||' '||decode(id, 0, 'Cost='||position) "Query   3 Plan_Table"   4 from plan_table   5 start with id = 0   6 connect by prior id = parent_id;   Query   Plan_Table   ---------------------------------------------------------   SELECT STATEMENT Cost=75   TABLE ACCESS BY INDEX ROWID T_PEEKING   INDEX RANGE SCAN T_PEEKING_IDX1   可以看出,在使用綁定變量時,參數OPTIMIZER_INDEX_COST_ADJ對于是否選擇索引會有重要的影響。   這裏我們暫且不討論索引掃描的原始成本是如何計算得出的。但是有一點很重要,在使用綁定變量時,計算出的成本是平均成本。在我們上面的例子中,字段B的值只有3個:"A"、"B"、"C",其中A最多,1003行中有1000行。因此,在索引上掃描值爲A記錄的成本爲1000/1003 * 索引全掃描成本 ≈索引全掃描成本,我們看下它的成本是多少: 以下是引用片段:   SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=100;   System altered.   SQL>   SQL> delete from plan_table;   2 rows deleted.   SQL>   SQL> explain plan for select   /*+index(a T_PEEKING_IDX1)*/* from T_PEEKING a where b = 'A';   Explained.   SQL>   SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||   2 object_name||' '||decode(id, 0, 'Cost='||position) "Query   3 Plan_Table"   4 from plan_table   5 start with id = 0   6 connect by prior id = parent_id;   Query   Plan_Table   --------------------------------------------------------------   SELECT STATEMENT Cost=336   TABLE ACCESS BY INDEX ROWID T_PEEKING   INDEX RANGE SCAN T_PEEKING_IDX1   可以看到,它的成本是336。因此索引的平均成本是(336 * 1003/1000) / 3 ≈ 113,也就是使用綁定變量使的成本。而掃描其它兩個值"B"和"A"時代價就非常小。 以下是引用片段: SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=100;   System altered.   SQL>   SQL> delete from plan_table;   3 rows deleted.   SQL>   SQL> explain plan for select   /*+index(a T_PEEKING_IDX1)*/* from T_PEEKING a where b = 'B';   Explained.   SQL>   SQL> select lpad(' ', 2*(level-1))||operation||' '||options||' '||   2 object_name||' '||decode(id, 0, 'Cost='||position) "Query   3 Plan_Table"   4 from plan_table   5 start with id = 0   6 connect by prior id = parent_id;   Query   Plan_Table   ---------------------------------------------------------------   SELECT STATEMENT Cost=2   TABLE ACCESS BY INDEX ROWID T_PEEKING   INDEX RANGE SCAN T_PEEKING_IDX1   因爲計算的成本是平均成本(相對實際掃描某個值的成本,平均成本更接近全表掃描成本),因此在創建查詢計劃時,使用綁定變量將更加容易受到參數OPTIMIZER_INDEX_COST_ADJ影響,特別是上面的這種情況(即索引字段的集的勢非常高時)下,平均代價與實際掃描某個值代價相差非常遠。這種情況下,OPTIMIZER_INDEX_COST_ADJ對不使用綁定變量查詢影響就非常小(因爲索引代價不是比全表掃描成本大很多就是小很多),不管掃描哪個值,不使用綁定變量將更加容易選擇到合理的查詢計劃。   綁定變量窺視   在了解了參數OPTIMIZER_INDEX_COST_ADJ的作用後。再了解一個對查詢計劃,特別是使用綁定變量時會産生重大影響的特性:綁定變量窺視(Bind Variables Peeking)。   綁定變量窺視是9i以後的一個新特性。它使CBO優化器在計算訪問代價時,將綁定變量傳入的值考慮進去,從而計算出更合理的成本(否則,將會計算平均成本)。看下面例子: 以下是引用片段: SQL> conn sys/sys as sysdba   Connected.   SQL>   SQL> alter system set OPTIMIZER_INDEX_COST_ADJ=60;   System altered.   SQL> analyze table T_PEEKING compute   statistics for table for all indexes for all indexed columns;   Table analyzed.   SQL>   SQL> set autot trace   SQL>   SQL> alter session set sql_trace = true;   Session altered.   SQL>   SQL> var v char(1)   SQL>   SQL> exec :v := 'A';   PL/SQL procedure successfully completed.   SQL>   SQL> select * from T_PEEKING a where b = :V;   1000 rows selected.   SQL>   SQL> alter session set sql_trace = false;   Session altered.   用Tkprof處理生成的trace文件。因爲在存在綁定變量窺視時,autotrace或者explain plan可能不會顯示正確的查詢計劃,需要Tkprof來處理sql trace。 tkprof fuyuncat_ora_5352.trc aaa.txt   此時OPTIMIZER_INDEX_COST_ADJ是60,根據上面的結論,似乎查詢計劃應該選擇掃描索引。但是,這裏給綁定變量賦了值"A",這時,優化器會「窺視」到這個值,並且在計算掃描成本時按照這個值的成本來計算。因此,得出的查詢計劃是全表掃描,而不是掃描索引,靠Tkprof分析的結果: 以下是引用片段: select * from T_PEEKING a where b = :V   call count cpu elapsed disk query current rows   ------- ------ -------- ---------- ---------- ---------- ---------- ----------   Parse 1 0.00 0.00 0 0 0 0   Execute 1 0.00 0.00 0 0 0 0   Fetch 68 0.01 0.07 0 406 0 1000   ------- ------ -------- ---------- ---------- ---------- ---------- ----------   total 70 0.01 0.08 0 406 0 1000   Misses in library cache during parse: 1   Optimizer mode: CHOOSE   Parsing user id: SYS   Rows Row Source Operation   ------- ---------------------------------------------------   1000 TABLE ACCESS FULL T_PEEKING (cr=406 pr=0 pw=0 time=5052 us)   但是,綁定變量窺視對一條語句只會使用一次。就是說,在第一次解析語句時,將綁定變量值考慮進去計算成本生成查詢計劃。以後在執行該語句時都采用這個查詢計劃,而不再考慮以後綁定變量的值是什麽了。 SQL> conn sys/sys as sysdba 以下是引用片段:   Connected.   SQL>   SQL>   SQL> set autot trace   SQL>   SQL> alter session set sql_trace = true;   Session altered.   SQL>   SQL> var v char(1)   SQL>   SQL> exec :v := 'B';   PL/SQL procedure successfully completed.   SQL>   SQL> select * from T_PEEKING a where b = :V;   1000 rows selected.   SQL>   SQL> alter session set sql_trace = false;   Session altered.   再用Tkprof分析生成的trace文件,看到盡管這裏的值是"B",選擇索引掃描會更優,但分析結果中查詢計劃還是使用全表掃描: select * 以下是引用片段:   from   T_PEEKING a where b = :V   call count cpu elapsed disk query current rows   ------- ------ -------- ---------- ---------- ---------- ---------- ----------   Parse 1 0.00 0.00 0 0 0 0   Execute 1 0.00 0.00 0 0 0 0   Fetch 2 0.00 0.00 0 340 0 2   ------- ------ -------- ---------- ---------- ---------- ---------- ----------   total 4 0.00 0.00 0 340 0 2   Misses in library cache during parse: 0   Optimizer mode: CHOOSE   Parsing user id: SYS   Rows Row Source Operation   ------- ---------------------------------------------------   2 TABLE ACCESS FULL T_PEEKING (cr=340 pr=0 pw=0 time=1005 us)   因此,這種情況下使用綁定變量也會導致無法選擇最優的查詢計劃。   綜上所述,我們可以得出一個結論:在對建有索引的字段(包括字段集),且字段(集)的集的勢非常大時,使用綁定變量可能會導致查詢計劃錯誤,因而會使查詢效率非常低。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有