Oracle foretrukne kolonnelængder

Der er ingen forskel i ydeevne. Og der er ingen skjulte optimeringer udført på grund af power of 2.

Det eneste, der gør en forskel i, hvordan tingene opbevares, er den faktiske data. 100 tegn gemt i en VARCHAR2(2000) kolonne gemmes på nøjagtig samme måde som 100 tegn gemt i en VARCHAR2(500) kolonne.

Tænk på længden som en forretningsmæssig begrænsning , ikke som en del af datatypen. Det eneste, der bør drive din beslutning om længden, er de forretningsmæssige begrænsninger for de data, der lægges ind der.

Rediger :den eneste situation, hvor længden gør gør en forskel, er når du har brug for et indeks på den kolonne. Ældre Oracle-versioner (<10) havde en grænse for nøglelængden, og det blev kontrolleret, da indekset blev oprettet.

Selvom det er muligt i Oracle 11, er det måske ikke det klogeste valg at have et indeks på en værdi med 4000 tegn.

Rediger 2 :

Så jeg var nysgerrig og satte en simpel test op:

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

Derefter fyldte begge tabeller med strenge sammensat af 40 'X'. Hvis der faktisk var en (væsentlig) forskel mellem lagringen, skulle dette på en eller anden måde vise sig, når du henter dataene, ikke?

Begge tabeller har præcis 1048576 rækker.

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>

Så den fulde tabelscanning for begge borde gjorde nøjagtig det samme. Så hvad sker der, når vi rent faktisk vælger dataene?

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>

Der er en lille forskel i konsistente gets, men det kan skyldes caching.