Não há diferença no desempenho. E não há otimizações ocultas feitas por causa da potência de 2.
A única coisa que faz diferença em como as coisas são armazenadas é o real dados. 100 caracteres armazenados em um
VARCHAR2(2000) coluna são armazenados exatamente da mesma forma que 100 caracteres armazenados em um VARCHAR2(500) coluna. Pense no comprimento como uma restrição de negócios , não como parte do tipo de dados. A única coisa que deve orientar sua decisão sobre o comprimento são as restrições de negócios sobre os dados que são colocados lá.
Editar :a única situação em que o comprimento não fazer a diferença, é quando você precisa de um índice nessa coluna. Versões mais antigas do Oracle (<10) tinham um limite no comprimento da chave e isso foi verificado ao criar o índice.
Embora seja possível no Oracle 11, pode não ser a escolha mais sábia ter um índice em um valor com 4.000 caracteres.
Editar 2 :
Então fiquei curioso e configurei um teste simples:
create table narrow (id varchar(40));
create table wide (id varchar(4000));
Em seguida, preencheu ambas as tabelas com strings compostas por 40 'X'. Se realmente houvesse uma diferença (substancial) entre o armazenamento, isso deveria aparecer de alguma forma ao recuperar os dados, certo?
Ambas as tabelas têm exatamente 1048576 linhas.
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>
Portanto, a varredura completa da tabela para ambas as tabelas fez exatamente o mesmo. Então, o que acontece quando realmente selecionamos os dados?
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>
Há uma pequena diferença em obtenções consistentes, mas isso pode ser devido ao armazenamento em cache.
