sql >> Databasteknik >  >> RDS >> Oracle

Oracle föredragna kolumner längder

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.




  1. Fatalt fel:Anrop till odefinierad funktion mysqli_result()

  2. Parameteriserade frågor med psycopg2 / Python DB-API och PostgreSQL

  3. Skapa en länkad server i SQL Server (T-SQL-exempel)

  4. lagra år i databasen