Oracle preferowane długości kolumn

Question

Czy współczynnik mnożenia długości kolumny w jakiś sposób wpływa na wydajność bazy danych?

Innymi słowy, jaka jest różnica między wykonywaniem dwóch poniższych tabelach:

TBL1: 
    - CLMN1 VARCHAR2(63) 
    - CLMN2 VARCHAR2(129) 
    - CLMN3 VARCHAR2(250) 

i

TBL2: 
    - CLMN1 VARCHAR2(64) 
    - CLMN2 VARCHAR2(128) 
    - CLMN3 VARCHAR2(256) 

powinniśmy zawsze próbować dokonać długość kolumna do jakiejś potęgi 2 czy tylko maksymalny rozmiar ma znaczenie?

Niektórzy programiści twierdzą, że istnieje związek między współczynnikiem mnożenia długości kolumn w bazie danych, ponieważ ma wpływ na to, jak Oracle dystrybuuje i zapisuje dane na dysku i udostępnia swoją pamięć podręczną w pamięci. Czy ktoś może to udowodnić lub obalić?

Answer 1

Nie ma różnicy w wydajności. I nie ma żadnych ukrytych optymalizacji z powodu siły 2.

Jedyne, co robi różnicę w przechowywaniu rzeczy, to aktualne dane. 100 znaków przechowywanych w kolumnie VARCHAR2(2000) jest przechowywanych w dokładnie taki sam sposób, jak 100 znaków przechowywanych w kolumnie VARCHAR2(500).

Pomyśl o długości jako ograniczeniu biznesowym , nie jako część typu danych. Jedyną rzeczą, która powinna kierować twoją decyzją o długości, są ograniczenia biznesowe związane z wprowadzanymi tam danymi.

Edit: jedyna sytuacja, w której długość ma zrobić różnicę, kiedy trzeba indeks na tej kolumnie. Starsze wersje Oracle (< 10) miały limit długości klucza i zostały sprawdzone podczas tworzenia indeksu.

Nawet jeśli jest to możliwe w Oracle 11, może nie być najmądrzejszym wyborem indeks na wartość z 4000 znaków.

Edycja 2:

Więc byłem ciekawy i konfiguracja prosty test:

create table narrow (id varchar(40)); 
create table wide (id varchar(4000)); 

Następnie pełnił obie tabele z ciągów składających się z 40 'x'. Jeśli rzeczywiście istniała (istotna) różnica między pamięcią masową, powinna to jakoś pokazać podczas pobierania danych, prawda?

Obie tabele mają dokładnie 1048576 wierszy.

 
Connected to: 
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production 
With the Partitioning, OLAP, Data Mining and Real Application Testing options 

SQL> set autotrace traceonly statistics 
SQL> select count(*) from wide; 


Statistics 
---------------------------------------------------------- 
      0 recursive calls 
      1 db block gets 
     6833 consistent gets 
      0 physical reads 
      0 redo size 
     349 bytes sent via SQL*Net to client 
     472 bytes received via SQL*Net from client 
      2 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
      1 rows processed 

SQL> select count(*) from narrow; 


Statistics 
---------------------------------------------------------- 
      0 recursive calls 
      1 db block gets 
     6833 consistent gets 
      0 physical reads 
      0 redo size 
     349 bytes sent via SQL*Net to client 
     472 bytes received via SQL*Net from client 
      2 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
      1 rows processed 

SQL> 

Tak więc pełne skanowanie tabeli dla obu tabel zrobiło dokładnie to samo. Co się dzieje, gdy faktycznie wybieramy dane?

 
SQL> select * from wide; 

1048576 rows selected. 


Statistics 
---------------------------------------------------------- 
      4 recursive calls 
      2 db block gets 
     76497 consistent gets 
      0 physical reads 
      0 redo size 
    54386472 bytes sent via SQL*Net to client 
    769427 bytes received via SQL*Net from client 
     69907 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
    1048576 rows processed 

SQL> select * from narrow; 

1048576 rows selected. 


Statistics 
---------------------------------------------------------- 
      4 recursive calls 
      2 db block gets 
     76485 consistent gets 
      0 physical reads 
      0 redo size 
    54386472 bytes sent via SQL*Net to client 
    769427 bytes received via SQL*Net from client 
     69907 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
    1048576 rows processed 

SQL> 

Występuje niewielka różnica w stałym wyniku, ale może to wynikać z buforowania.