none
Stored Procedure Or Query RRS feed

  • Domanda

  • Hello,

    my question is simple: In order to retrieve records from a table, is it more performat a stored procedure or a query?

    Italiano: "per recuperare record da una tabella, è più performante una stored procedure o una query"?

    Thank you

     

    Diego

    giovedì 23 settembre 2010 17:33

Risposte

  • Diego81 wrote:

    Hello,

    my question is simple: In order to retrieve records from a table, is it more performat a stored procedure or a query?

    Italiano: "per recuperare record da una tabella, è più performante una stored procedure o una query"?

    La domanda in inglese è inutile, considerato che questi forum sono solo per la lingua italiana, come puoi leggere da tutti gli altri post.
     Se la query viene "preparata" (vedi metodo Prepare del command di ado.net) e il command usa i parametri, la performance del command è pari alla migliore performance di una stored procedure sul server

    Se non usi i parameters ma concateni i valori nella query, sei soggetto a enormi problemi di sicurezza (sql injection) e ottieni pessime performance perché ad ogni esecuzione la query deve essere ri-parsata e ri-compilata.

    Se sul lato server hai una stored procedure che compone dinamicamente la query testuale, hai performance pessime così come nel caso della query e sei soggetto anche ad un altro gravissimo attacco di sicurezza chiamato "sql truncation".

    Per vedere nella pratica se la tua query o stored procedure sono soggette a ricompilazione puoi usare il performance monitor di Windows (perfmon.exe) sul server e monitorare le ricompilazioni al secondo. Solo questo ti darà una risposta certa.

    Per vedere cosa viene prodotto dall'esecuzione della tua query puoi usare il SQL Profiler. Nel caso di esecuzione multipla di una query parametrizzata valorizzata ad ogni giro con valori differenti, nel profiler vedrai una volta la query ed enne volte l'esecuzione con il passaggio di valori.
    In questo specifico caso la "Prepare" consente di anticipare a sql server che stai per eseguire un command con tanti valori differenti.
    Se non esegui la Prepare, la prima volta che esegui il command verrà fatta la prepare "implicita" e le volte successive avrai il top delle performance.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    giovedì 23 settembre 2010 18:39
  • Mah, detta così lascia il tempo che trova.

    Una stored procedure viene compilata la prima volta che viene eseguita, le volte successive SQL non deve ri-interpretare il codice ogni volta come accade per una query. In linea teorica, quindi è più performante.

    Ovviamente se la stored procedure è scritta come si deve. Per esperienza personale ho visto stored procedure scritte male meno performanti delle query generate da LINQ to SQL o EF.

    Quando valuti, però, l'utilizzi l'uso di Stored o di accesso tramite uno strato DAL non devi, a mio modesto avviso, valutare solo ed esclusivamente le performance ma anche la manutenibilità ed altre caratteristiche.

    giovedì 23 settembre 2010 18:46

Tutte le risposte

  • Diego81 wrote:

    Hello,

    my question is simple: In order to retrieve records from a table, is it more performat a stored procedure or a query?

    Italiano: "per recuperare record da una tabella, è più performante una stored procedure o una query"?

    La domanda in inglese è inutile, considerato che questi forum sono solo per la lingua italiana, come puoi leggere da tutti gli altri post.
     Se la query viene "preparata" (vedi metodo Prepare del command di ado.net) e il command usa i parametri, la performance del command è pari alla migliore performance di una stored procedure sul server

    Se non usi i parameters ma concateni i valori nella query, sei soggetto a enormi problemi di sicurezza (sql injection) e ottieni pessime performance perché ad ogni esecuzione la query deve essere ri-parsata e ri-compilata.

    Se sul lato server hai una stored procedure che compone dinamicamente la query testuale, hai performance pessime così come nel caso della query e sei soggetto anche ad un altro gravissimo attacco di sicurezza chiamato "sql truncation".

    Per vedere nella pratica se la tua query o stored procedure sono soggette a ricompilazione puoi usare il performance monitor di Windows (perfmon.exe) sul server e monitorare le ricompilazioni al secondo. Solo questo ti darà una risposta certa.

    Per vedere cosa viene prodotto dall'esecuzione della tua query puoi usare il SQL Profiler. Nel caso di esecuzione multipla di una query parametrizzata valorizzata ad ogni giro con valori differenti, nel profiler vedrai una volta la query ed enne volte l'esecuzione con il passaggio di valori.
    In questo specifico caso la "Prepare" consente di anticipare a sql server che stai per eseguire un command con tanti valori differenti.
    Se non esegui la Prepare, la prima volta che esegui il command verrà fatta la prepare "implicita" e le volte successive avrai il top delle performance.


    Raffaele Rialdi  http://www.iamraf.net
    Weblog: http://blogs.ugidotnet.org/raffaele
    Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
    UGIdotNET - http://www.ugidotnet.org/


    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    giovedì 23 settembre 2010 18:39
  • Mah, detta così lascia il tempo che trova.

    Una stored procedure viene compilata la prima volta che viene eseguita, le volte successive SQL non deve ri-interpretare il codice ogni volta come accade per una query. In linea teorica, quindi è più performante.

    Ovviamente se la stored procedure è scritta come si deve. Per esperienza personale ho visto stored procedure scritte male meno performanti delle query generate da LINQ to SQL o EF.

    Quando valuti, però, l'utilizzi l'uso di Stored o di accesso tramite uno strato DAL non devi, a mio modesto avviso, valutare solo ed esclusivamente le performance ma anche la manutenibilità ed altre caratteristiche.

    giovedì 23 settembre 2010 18:46