sql >> Databáze >  >> RDS >> Oracle

Oracle preferoval délky sloupců

Rozdíl ve výkonu není žádný. A díky síle 2 nejsou prováděny žádné skryté optimalizace.

Jediná věc, která má vliv na to, jak jsou věci uloženy, je skutečné data. 100 znaků uložených v VARCHAR2(2000) sloupec jsou uloženy přesně stejným způsobem jako 100 znaků uložených v VARCHAR2(500) sloupec.

Délku si představte jako obchodní omezení , nikoli jako součást datového typu. Jediná věc, která by měla ovlivnit vaše rozhodnutí o délce, jsou obchodní omezení týkající se dat, která jsou tam vložena.

Upravit :jediná situace, kdy délka není udělat rozdíl, je, když potřebujete index na tomto sloupci. Starší verze Oracle (<10) měly limit na délku klíče a to bylo zkontrolováno při vytváření indexu.

I když je to možné v Oracle 11, nemusí být nejmoudřejší volbou mít index na hodnotě se 4000 znaky.

Úprava 2 :

Takže jsem byl zvědavý a nastavil jsem jednoduchý test:

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

Poté vyplňte obě tabulky řetězci složenými ze 40 'X'. Pokud skutečně existoval (podstatný) rozdíl mezi úložištěm, mělo by se to nějak projevit při načítání dat, ne?

Obě tabulky mají přesně 1048576 řádků.

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že úplné skenování tabulek pro oba stoly udělalo přesně totéž. Co se tedy stane, když data skutečně vybereme?

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>

Existuje malý rozdíl v konzistentních získávání, ale to může být způsobeno ukládáním do mezipaměti.




  1. Aktualizovat podřetězec sloupce

  2. Jak vytvořit funkci SQL Server pro spojení více řádků z poddotazu do jednoho odděleného pole?

  3. Agregáty a dělení

  4. MySQL ORDER BY nejvyšší počet řádků v jiné tabulce