Sarebbe meglio dividere i piani di query per dichiarazione per riusabilità?

Dalla mia limitata conoscenza di come i piani di query vengono compilati, archiviati e recuperati dalle query, capisco che una query multiistruzione o una procedura memorizzata genererà il suo piano di query che verrà archiviato nella cache del piano di query per essere utilizzato dalla query in future esecuzioni.

Penso che questo piano venga recuperato dalla cache del piano di query con l'hash della query, il che significa che se la query viene modificata ed eseguita, l'hash è diverso e viene generato un nuovo piano poiché non è possibile trovare hash corrispondenti nella cache del piano di query.

La mia domanda è: se un utente esegue un'istruzione che è una delle istruzioni nella query con più istruzioni, può utilizzare quella parte rilevante del piano di query già nella cache per la query con più istruzioni? Mi aspetto che la risposta sia no perché i valori di hash ovviamente non corrisponderanno, ma sarebbe meglio eseguire l'hashing di ogni istruzione in una query multiistruzione in modo che possano essere utilizzati dagli utenti che eseguono singole istruzioni dalla query?

Mi aspetto che ci siano complicazioni che non sto prendendo in considerazione (ed è queste che voglio davvero conoscere), ma sembra che potremmo memorizzare lo stesso "piano di istruzioni" in molti piani di query occupando più spazio e occupando di più CPU e tempo per generare.

Potrebbe solo mostrare la mia ignoranza però.

Se un utente esegue un'istruzione che è una delle istruzioni nella query con più istruzioni, può utilizzare quella parte rilevante del piano di query già nella cache per la query con più istruzioni?

No. L'unità di base del riutilizzo del piano in SQL Server è il batch .

Sarebbe meglio eseguire l'hashing di ogni istruzione in una query con più istruzioni in modo che possano essere utilizzate dagli utenti che eseguono singole istruzioni dalla query?

Un sistema ottimizzato per livelli elevati di riutilizzo del piano inserirà il codice comune (con una granularità adeguata) in oggetti riutilizzabili (ad es. Procedure, funzioni, trigger) su SQL Server. Parametrizzerà inoltre in modo esplicito qualsiasi codice generato dall'applicazione o lato client. Per il massimo riutilizzo del piano, questi batch generati dovrebbero differire solo nei valori dei parametri.

Mi aspetto che ci siano complicazioni che non sto prendendo in considerazione

Sembra che ti stia chiedendo perché SQL Server è stato progettato per essere memorizzato nella cache e riutilizzato a livello di batch, piuttosto che a livello di istruzione. Dubito che chiunque, a parte i designer originali, possa rispondere in modo autorevole a questa domanda. Ad ogni modo, mi sembra che un batch sia una granularità naturale da utilizzare perché è un'unità di lavoro naturale relativamente autonoma e rappresenta un ragionevole compromesso tra complessità di implementazione e probabilità di riutilizzo del piano.

Vi sono alcune cose che rendono i lotti non completamente autonomi (ad esempio tabelle temporanee locali create e referenziate attraverso i limiti delle procedure memorizzate). Queste eccezioni riducono l'ortogonalità e nel corso degli anni sono state associate a comportamenti e bug inaspettati "di progettazione".