SQL Server Performance Blog where milliseconds matter

 Hi Guys, Welcome back to this blog. This will be a light post just to review some important concepts that i have already discussed in the past. We talked about the Sargable concept here: Write high performing query: Is your query SARGABLE? Sargable Queries part 2. Examples   In shoert, your query is sargable when it can use index by doing a SEEK (and not a SCAN) operation. This way you can read from a table only the specific rows  you need. This approach is also the only  one that leads to scalable performance. We have already seen that functions are not Sargable and we have seen some examples and therefore our ISNULL function is also not! So how can we proceed? so how can we write the same logic in a sargable way? How to replace the ISNULL function using Sargable logic Suppose you are reading data from a table.  Table in our example is JDT1 , a standard Journal Entry Table from SAP ONE. You need to extract rows where the column SourceId is equal to 420. Now if...

Dear Readers, Today we return to the SARGABLE Queries topic started some days ago.   Let's take some examples of Queries that are SARGABLE and Query that are not! If you missed the first "episode" you still don't know the importance of SARGABLE Queries read my previous article  here Ready? I hear you say: yes yes.. So let's go!  Some Examples Let's create a simple test table and fill it with a bit of data: CREATE TABLE ELENCO (ID INT IDENTITY(1,1), CODICE VARCHAR(3) CONSTRAINT PK_Elenco_ID PRIMARY KEY CLUSTERED (id)) The ID field is self-incrementing and is the clustered index. As a first example , let's write one of the simpler Queries SELECT ID FROM LIST WHERE ID = 5 Let's see the execution plan: As we would expect the clustered index is used and a SEEK operation is performed. Now let's change the Query slightly: SELECT ID FROM LIST WHERE ID + 1 = 5 ...

Hi Guys, Today i wanna talk about performance that is the subject I like best! . I told you about this topic a few months ago Here . However, the article was written in Italian; I decided to translate it into English for the benefit of all. I hope you like it! Introduction: When a Query is a performing Query?   First concept! A Query is a performing Query when it takes advantage of the presence of the indexes present on the tables. Only in this way infact data will be extracted fast Obviously we can create tables without indexes (called HEAP tables) but in this case the only way to extract data will be to read the table entirely. This concept must be clear! Let's see it through a simple example: Create a PERSON table with these three columns: ID, FIRSTNAME and LASTNAME. Then we perform this simple query: SELECT FIRSTNAME FROM PERSON WHERE FIRSTNAME = 'LUCA'   If we look at the execution plan, we immediately see that...

Ben ritrovati! Anche oggi articolo leggero leggero.. Continuiamo con  il discorso di ieri che trovate qui: SQL Server: Come fare ricerche CASE SENSITIVE Abbiamo visto come eseguire una ricerca CASE SENSITIVE anche se il database non lo è. Abbiamo visto infatti che possiamo sfruttare la COLLATE per ottenere il risultato voluto. Ad esempio scrivendo una Query così: SELECT * FROM ELENCO WHERE CODICE COLLATE SQL_Latin1_General_CP1_CS_AS = 'luca' La domandi di oggi è la seguente: Ma se specifico una COLLATE nella WHERE, la stringa SQL che ottengo, è SARGABLE?    La collate è Sargable? Vediamolo, eseguiamo quindi la nostra Query e guardiamone il piano di esecuzione...   Che ne dite? Sul campo CODICE esiste un indice non clustered.   Di questo indice però ne viene fatta la scansione (SCAN) e non la SEEK e quindi la nostra Query NON E' SARGABLE! SQL Server sarà costretto a scorrersi e leggersi tutto l'indice e come risultato avremo scarse perfor...

Ciao Ragazzi, Oggi torniamo sulle Query SARGABLE. Facciamo alcuni esempi di Query che sono SARGABLE e di Query che non lo sono! Se vi siete persi la prima "puntata" è ancora non sapete l'importanza delle Query SARGABLE leggete prima il mio precedente articolo:  Scrivere Query performanti ...la tua Query è SARGABLE?   Siete pronti!  Via! Creiamoci una semplice tabella di prova e riempiamola con un po di dati: CREATE TABLE ELENCO (ID INT IDENTITY(1,1), CODICE VARCHAR(3) CONSTRAINT PK_Elenco_ID PRIMARY KEY CLUSTERED (id)) Il campo ID è autoincrementante ed è l'indice clustered. Come primo esempio , scriviamo una delle Query più semplici SELECT ID FROM ELENCO WHERE ID = 5 Vediamo il piano di esecuzione: Come ci aspetteremmo per estrarre il dato voluto viene utilizzato l'indice clustered e viene effettuata una operazione di SEEK. Ora cambiamo leggermente la Query: SELECT ID FROM ELENCO WHERE ID + 1 = 5 Gua...

Cari lettori, oggi si cambia argomento! Siete stati bravi: avete resistito a ben tre miei articoli sul database TEMPDB di SQL Server e quindi oggi parliamo d'altro.. Volevo infatti iniziare a parlare di come scrivere Query che siano performanti. Premetto che sarà, per forza di cose, una introduzione nella quale volutamente non scenderò in dettagli. L'obbiettivo per oggi è infatti focalizzare l'attenzione, più che altro, sui concetti principali. Ma come al solito, se avete domande, scrivetemi!   Iniziamo! Diciamo subito che una Query è performante quando sfrutta la presenza degli indici presenti sulle tabelle ; solo in questo modo infatti i dati verranno estratti "velocemente". Ovviamente possiamo creare anche tabelle prive di indici (che sono dette tabelle HEAP), in questo caso però l'unico modo per recuperare i dati sarà quello di leggere completamente la tabella. Vediamolo chiaramente con un semplice esempio: Per prima cosa creiamo una tabella PERSON...