sql >> Database teknologi >  >> RDS >> Oracle

Statisk vs dynamisk sql

Din eksempelkode er så enkel, at der vil være lille forskel, men i så fald ville den statiske version højst sandsynligt fungere bedre.

Hovedårsagen til at bruge dynamisk SQL til ydeevne er, når SQL-sætningen kan variere betydeligt - dvs. du kan muligvis tilføje ekstra kode til WHERE-sætningen under kørsel baseret på systemets tilstand (begrænset af en underforespørgsel) på adresse, hvis adresse er indtastet osv.).

En anden grund er, at det nogle gange kan virke kontraproduktivt at bruge Bind-variabler som parametre.

Et eksempel er, hvis du har noget som et statusfelt, hvor data ikke er jævnt fordelt (men er indekseret).

Overvej følgende 3 udsagn, når 95 % af dataene er 'behandlet

   SELECT col FROM table 
   WHERE status = 'U'-- unprocessed
   AND company = :company

   SELECT col FROM table 
   WHERE status = 'P' -- processed
   AND company = :company

   SELECT col FROM table
   WHERE status = :status
   AND company = :company

I den endelige version vil Oracle vælge en generisk forklaringsplan. I den første version kan det beslutte, at den bedste plan er at starte med indekset på status (vel vidende at 'ubehandlede poster er en meget lille del af totalen).

Du kan implementere det gennem forskellige statiske sætninger, men hvor du har mere komplekse sætninger, som kun ændres med et par tegn, kan dynamisk SQL være en bedre mulighed.

Ulemper

Hver gentagelse af den samme dynamiske SQL-sætning medfører en blød parse, som er en lille overhead sammenlignet med en statisk sætning, men stadig en overhead.

Hver NY sql-sætning (dynamisk eller statisk) medfører også en lås på SGA'en (delt hukommelse) og kan resultere i at "gamle" sætninger skubbes ud.

Et dårligt, men almindeligt systemdesign er, at nogen bruger dynamisk SQL til at generere simple valg, der kun varierer efter nøgle - dvs.

SELECT col FROM table WHERE id = 5
SELECT col FROM table WHERE id = 20
SELECT col FROM table WHERE id = 7

De enkelte udsagn vil være hurtige, men den overordnede systemydelse vil forringes, da det dræber de delte ressourcer.

Desuden er det langt sværere at fange fejl på kompileringstidspunktet med dynamisk SQL. Hvis du bruger PL/SQL, smider dette et godt tjek af kompileringstid væk. Selv når du bruger noget som JDBC (hvor du flytter al din databasekode ind i strenge - god idé!) kan du få pre-parsere til at validere JDBC-indholdet. Dynamisk SQL =kun køretidstest.

Overhead

Overheaden for execute immediate er lille - den er i tusindedele af et sekund - dog kan den tælle op, hvis dette er inde i en loop / på en metode kaldet én gang pr. objekt / osv. Jeg fik engang en 10x hastighedsforbedring ved at erstatte dynamisk SQL med genereret statisk SQL. Dette komplicerede imidlertid koden, og det blev kun gjort, fordi vi krævede hastigheden.



  1. Matchende udbud med efterspørgsel Udfordring

  2. Vælg (hent) alle poster fra flere skemaer ved hjælp af Postgres

  3. SQLite grupper efter/tæl timer, dage, uger, år

  4. onCreate() af RoomDatabase.Callback() blev ikke kaldt efter et vellykket kald til .build()