增幅列在甲骨文

大小的影響，我有一個劇本增幅列在甲骨文

SQL script: alter table xx_vms.es_lot_updates modify (routing_list varchar2(1000));

本專欄以前的大小爲255。現在我常常會增加它的大小爲1000 但在該表中，列routing_list一片空白。偶爾它有價值。

此列的增量大小是否會造成性能問題？我很困惑！請幫忙。謝謝。

來源

2013-05-15 duykaka

不，沒有性能問題。您所做的只是允許在該列中插入更大的文本字符串。請記住，您應始終儘可能嚴格地對待表格中允許的內容，您可以根據需要隨意製作列。（varchar2的最大4000字節）

來源

2013-05-15 09:35:33 winkbrace

這是一個好消息。謝謝。 – duykaka

這取決於。帶有varchar2（1000）的表格使用更多的數據庫塊進行存儲，因此，當您要讀取更多的塊時，全表掃描可能會更加昂貴。這裏有一個簡單的測試：

17:48:25 [email protected]> create table c1000 (txt varchar2(1000)); 

Table created. 

Elapsed: 00:00:00.21 
17:48:37 [email protected]> create table c255 (txt varchar2(255)); 

Table created. 

Elapsed: 00:00:00.03 

-- for this test we assume that only 10% of columns are filled with data 
17:50:21 [email protected]> ed 
Wrote file S:\spool\sandbox\BUFFER_HR_32.sql 

    1 insert into c255 
    2 select decode(mod(rownum,10), 0, lpad('x', 255,'x')) from dual 
    3* connect by rownum <= 1e5 
17:50:24 [email protected]>/

100000 rows created. 

Elapsed: 00:00:01.26 
17:50:47 [email protected]> ed 
Wrote file S:\spool\sandbox\BUFFER_HR_32.sql 

    1 insert into c1000 
    2 select decode(mod(rownum,10), 0, lpad('x', 1000,'x')) from dual 
    3* connect by rownum <= 1e5 
17:50:51 [email protected]>/

100000 rows created. 

Elapsed: 00:00:01.45 
17:50:52 [email protected]> commit; 

Commit complete. 

Elapsed: 00:00:00.01 
17:51:20 [email protected]> select table_name, blocks from user_tables where table_name in ('C255', 'C1000'); 

TABLE_NAME       BLOCKS 
------------------------------ ---------- 
C1000        1756 
C255         622 

Elapsed: 00:00:00.20 
17:53:28 [email protected]> set autotrace traceonly statistics 
17:53:37 [email protected]> select * from c1000; 

100000 rows selected. 

Elapsed: 00:00:01.30 

Statistics 
---------------------------------------------------------- 
      1 recursive calls 
      0 db block gets 
     1901 consistent gets 
     1694 physical reads 
      0 redo size 
    10586458 bytes sent via SQL*Net to client 
     2552 bytes received via SQL*Net from client 
     201 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
    100000 rows processed 

17:53:50 [email protected]> select * from c255; 

100000 rows selected. 

Elapsed: 00:00:00.63 

Statistics 
---------------------------------------------------------- 
      1 recursive calls 
      0 db block gets 
     825 consistent gets 
     295 physical reads 
      0 redo size 
    3107206 bytes sent via SQL*Net to client 
     2552 bytes received via SQL*Net from client 
     201 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
    100000 rows processed

看看consistent gets統計。與完整掃描c255相比，完全掃描c1000可以實現兩倍的IO。

但是，如果您使用主鍵僅選擇幾行，我認爲您不會注意到顯着差異。

來源

2013-05-15 10:04:31

你正在證明的是，更大的表需要更長的時間從磁盤讀取比較小的一個:)在OP的情況下，他只增加了容量，所以他不會看到你演示的效果。 – Ronnis

@羅尼斯他有理由提高能力，不是嗎？我猜想他會在那裏儲存更多的數據 –

也許。我的觀點是：在VARCHAR2的情況下，增加*容量和*利用*容量之間存在差異。他在詢問「這個專欄的增量大小是否會造成績效問題」，而不是。但是利用這種能力會是這樣，這就是你的測試案例所展示的。我只是想幫你寫一個更細緻的答案。 – Ronnis

不，它已經沒有太多做的性能，VARCHAR2最大尺寸爲4000

一旦你改變表做remeber編譯所有的依賴，因爲他們將是無效的，例如

程序和包

來源

2013-05-15 10:15:22 abhi

增幅列在甲骨文

回答

相關問題