Det är ingen skillnad i prestanda. Och det finns inga dolda optimeringar gjorda på grund av kraften hos 2.
Det enda som gör skillnad i hur saker lagras är den faktiska data. 100 tecken lagrade i en VARCHAR2(2000)
kolumnen lagras exakt på samma sätt som 100 tecken lagrade i en VARCHAR2(500)
kolumn.
Tänk på längden som en affärsbegränsning , inte som en del av datatypen. Det enda som bör styra ditt beslut om längden är affärsbegränsningarna för den data som läggs in där.
Redigera :den enda situationen där längden gör göra skillnad, är när du behöver ett index på den kolumnen. Äldre Oracle-versioner (<10) hade en gräns för nyckellängden och det kontrollerades när indexet skapades.
Även om det är möjligt i Oracle 11, kanske det inte är det klokaste valet att ha ett index på ett värde med 4000 tecken.
Redigera 2 :
Så jag var nyfiken och gjorde ett enkelt test:
create table narrow (id varchar(40));
create table wide (id varchar(4000));
Fyllde sedan båda tabellerna med strängar bestående av 40 'X'. Om det verkligen fanns en (väsentlig) skillnad mellan lagringen, borde detta visa sig på något sätt när data hämtas, eller hur?
Båda tabellerna har exakt 1048576 rader.
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 fullständiga tabellskanningen för båda tabellerna gjorde exakt samma sak. Så vad händer när vi faktiskt väljer data?
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>
Det finns en liten skillnad i konsekventa gets, men det kan bero på cachning.