sql >> Databasteknik >  >> RDS >> Oracle

Statisk vs dynamisk sql

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.



  1. SQL ALTER TABLE Syntax – Listad av DBMS

  2. PL/pgSQL anonymt kodblock

  3. Hur man skapar en tom SQLite-databas

  4. Hur man beräknar löpande totalsumma i rödförskjutning