Din exempelkod är så enkel att det blir liten skillnad, men i så fall skulle den statiska versionen med största sannolikhet fungera bättre.
Den främsta anledningen till att använda dynamisk SQL för prestanda är när SQL-satsen kan variera på ett betydande sätt - det vill säga du kanske kan lägga till extra kod till WHERE-satsen vid körning baserat på systemets tillstånd (begränsa av en underfråga på adress, om adress har angetts, etc).
En annan anledning är att det ibland kan vara kontraproduktivt att använda Bind-variabler som parametrar.
Ett exempel är om du har något som ett statusfält, där data inte är jämnt fördelad (men är indexerad).
Tänk på följande 3 påståenden, när 95 % av datan är 'bearbetad
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 slutliga versionen kommer Oracle att välja en generisk förklaringsplan. I den första versionen kan det besluta att den bästa planen är att börja med indexet på status (med vetskapen om att "Obehandlade poster är en mycket liten del av summan).
Du kan implementera det genom olika statiska satser, men där du har mer komplexa satser som bara ändras med ett par tecken, kan dynamisk SQL vara ett bättre alternativ.
Nackdelar
Varje upprepning av samma dynamiska SQL-sats medför en mjuk analys, vilket är en liten overhead jämfört med en statisk sats, men fortfarande en overhead.
Varje NY sql-sats (dynamisk eller statisk) har också ett lås på SGA (delat minne) och kan resultera i att "gamla" satser trycks ut.
En dålig, men vanlig, systemdesign är att någon använder dynamisk SQL för att generera enkla val som bara varierar med nyckel - dvs.
SELECT col FROM table WHERE id = 5
SELECT col FROM table WHERE id = 20
SELECT col FROM table WHERE id = 7
De individuella uttalandena kommer att vara snabba, men den övergripande systemets prestanda kommer att försämras eftersom det tar död på de delade resurserna.
Dessutom är det mycket svårare att fånga fel vid kompilering med dynamisk SQL. Om du använder PL/SQL försvinner detta en bra kontroll av kompileringstid. Även när du använder något som JDBC (där du flyttar all din databaskod till strängar - bra idé!) kan du få pre-parsers för att validera JDBC-innehållet. Dynamisk SQL =endast körtidstestning.
Omkostnader
Overheaden för exekvering omedelbart är liten - den är i tusendelar av en sekund - men det kan läggas ihop om detta är inuti en loop / på en metod som kallas en gång per objekt / etc. Jag fick en gång en 10x hastighetsförbättring genom att ersätta dynamiskt SQL med genererad statisk SQL. Detta komplicerade dock koden och gjordes bara för att vi krävde hastigheten.