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.