Database
 sql >> Database >  >> RDS >> Database

Suggerimenti per le prestazioni XML

L'analisi dei dati da XML utilizzando XQuery è una pratica di routine. Per farlo nel modo più efficace, è necessario un piccolo sforzo.

Supponiamo di dover analizzare i dati dal file del disco con la seguente struttura:

<tables>
<table name="Accounting" schema="Production" object="Accounting">
<column name="Date" order="3" visible="1" />
<column name="DateFrom" order="5" visible="1" />
<column name="DateTo" order="6" visible="1" />
<column name="Description" order="4" visible="1" />
<column name="DocumentUID" order="1" visible="0" />
<column name="Number" order="2" visible="1" />
<column name="Warehouse" order="7" visible="1" />
</table>
</tables>

Usa BULK INSERT, se hai bisogno di leggere i dati da un file:

SELECT BulkColumn
FROM OPENROWSET(BULK 'D:\data.xml', SINGLE_BLOB) x sample xml file

Un file xml di esempio è qui.

Tuttavia, tieni presente una cosa in particolare... Cerca di non leggere i dati direttamente:

;WITH cte AS
(
SELECT x = CAST(BulkColumn AS XML)
FROM OPENROWSET(BULK 'D:\data.xml', SINGLE_BLOB) x
)
SELECT t.c.value('@name', 'VARCHAR(100)')
FROM cte
CROSS APPLY x.nodes('tables/table') t(c)

Assegna dati a una variabile. In questo modo puoi ottenere un piano di esecuzione più efficiente:

DECLARE @xml XML
SELECT @xml = BulkColumn
FROM OPENROWSET(BULK 'D:\data.xml', SINGLE_BLOB) x

SELECT t.c.value('@name', 'VARCHAR(100)')
FROM @xml.nodes('tables/table') t(c)

Confronta i risultati:

Table 'Worktable'. Scan count 0, logical reads 729, physical reads 0, read-ahead reads 0, lob logical reads 62655,...
SQL Server Execution Times:
CPU time = 1203 ms, elapsed time = 1214 ms.

Table 'Worktable'. Scan count 0, logical reads 7, physical reads 0, read-ahead reads 0, lob logical reads 202,....
SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 4 ms.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 3 ms.

Come puoi vedere, la seconda opzione è sostanzialmente più veloce.

Un'altra caratteristica importante di SQL Server quando si lavora con XQuery è che la lettura di un elemento padre può comportare prestazioni scadenti. Considera il seguente esempio:

SET STATISTICS PROFILE OFF

DECLARE @xml XML
SELECT @xml = BulkColumn
FROM OPENROWSET(BULK 'D:\data.xml', SINGLE_BLOB) x

SET STATISTICS PROFILE ON

SELECT
t.c.value('@name', 'SYSNAME')
, t.c.value('@order', 'INT')
, t.c.value('@visible', 'BIT')
, t.c.value('../@name', 'SYSNAME')
, t.c.value('../@schema', 'SYSNAME')
, t.c.value('../@object', 'SYSNAME')
FROM @xml.nodes('tables/table/*') t(c)

Diamo un'occhiata al numero effettivo di righe ricevute dall'operatore. Il valore è anormalmente grande:

La richiesta può essere facilmente ottimizzata utilizzando CROSS APPLY:

SELECT
t2.c2.value('@name', 'SYSNAME')
, t2.c2.value('@order', 'INT')
, t2.c2.value('@visible', 'BIT')
, t.c.value('@name', 'SYSNAME')
, t.c.value('@schema', 'SYSNAME')
, t.c.value('@object', 'SYSNAME')
FROM @xml.nodes('tables/table') t(c)
CROSS APPLY t.c.nodes('column') t2(c2)

Confrontiamo il tempo di esecuzione:

(1408 row(s) affected)
SQL Server Execution Times:
CPU time = 10125 ms, elapsed time = 10135 ms.

(1408 row(s) affected)
SQL Server Execution Times:
CPU time = 78 ms, elapsed time = 156 ms.

Come puoi vedere dall'esempio, la richiesta con CROSS APPLY funziona istantaneamente.

Grazie per l'attenzione. Spero che questo articolo sia stato utile. Sentiti libero di fare qualsiasi domanda, lasciare i tuoi commenti e suggerimenti su questo articolo.