No hay diferencia en el rendimiento. Y no se realizan optimizaciones ocultas debido a la potencia de 2.
Lo único que marca la diferencia en cómo se almacenan las cosas es el real datos. 100 caracteres almacenados en un VARCHAR2(2000) se almacenan exactamente de la misma manera que 100 caracteres almacenados en un VARCHAR2(500) columna.
Piense en la longitud como una restricción comercial , no como parte del tipo de datos. Lo único que debería impulsar su decisión sobre la longitud son las restricciones comerciales sobre los datos que se colocan allí.
Editar :la única situación en la que la longitud no marcar la diferencia, es cuando necesita un índice en esa columna. Las versiones anteriores de Oracle (<10) tenían un límite en la longitud de la clave y eso se verificó al crear el índice.
Aunque es posible en Oracle 11, puede que no sea la opción más inteligente tener un índice en un valor con 4000 caracteres.
Editar 2 :
Así que tenía curiosidad y configuré una prueba simple:
create table narrow (id varchar(40));
create table wide (id varchar(4000));
Luego llenó ambas tablas con cadenas compuestas por 40 'X'. Si de hecho hubo una diferencia (sustancial) entre el almacenamiento, esto debería aparecer de alguna manera al recuperar los datos, ¿verdad?
Ambas tablas tienen exactamente 1048576 filas.
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>
Entonces, el escaneo completo de la tabla para ambas tablas hizo exactamente lo mismo. Entonces, ¿qué sucede cuando realmente seleccionamos los datos?
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>
Hay una ligera diferencia en las obtenciones consistentes, pero eso podría deberse al almacenamiento en caché.
