Join sql e campi indicizzati

mercoledì 19 giugno 2013 - 09.47

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags VB.NET

trinity Profilo | Guru

3.465 messaggi | Data Invio: mer 19 giu 2013 - 09:47

buongiorno,
mi sorge un dubbio e quindi mi rivolgo al voi...ho diverse tabelle in un db sql server 2008, quando devo far vedere al cliente i dati a video eseguo tra queste tre tabelle delle select con all'interno delle join in quanto. adesso per rendere le select più veloci è giusto che io nelle tabelle indicizzo i campi che utilizzo nel confronto quando scrivo delle join?

esempio

select tab1.nome,tab1.cognome,tab2.nomestato from tab1
join
tab2
on tab1.idstato=tab2.id

in pratica nella tabella tab1 ho un campo indicizzato chiamato idstato nel quale salvo il valore id della tabella tab2 nella quale il campo id è la primary key.
Pertanto tornando alla mia domanda è giusto che io il campo tab1.idstato lo indicizzo?

spero di essermi fatto capire

ciao

Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

HolidaySoft.it Profilo | Junior Member

100 messaggi | Data Invio: mer 19 giu 2013 - 10:15

Ti confermo che quanto hai scritto è corretto.

Ciao
Mik
http://www.HolidaySoft.it
http://www.GarganoSapori.it - Olio ExtraVergine del Gargano
http://www.osteriaoristorante.it - Crea la Vetrina per il tuo Ristorante

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 19 giu 2013 - 13:00

>buongiorno,
ciao

>in pratica nella tabella tab1 ho un campo indicizzato chiamato
>idstato nel quale salvo il valore id della tabella tab2 nella
>quale il campo id è la primary key.
>Pertanto tornando alla mia domanda è giusto che io il campo tab1.idstato
>lo indicizzo?
di certo velocizza questa query, ma aggiungerei qualcosa.
Visto che usi SQL Server 2008 puoi anche pensare a due cose molto importanti che ti consentono di tenere l'indice snello e più performante ancora:
- filter, puoi indicizzare solo un subset di dati senza fare partizioni
- included columns, puoi aggiungere a livello foglia dell'indice i campi che usi nelle select (per quella tabella o per le query per cui l'indice serve) per evitare le Key Lookup

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: mer 19 giu 2013 - 13:12

ottimo ma nn so da dove iniziare mai sentite queste opzioni purtroppo..hai qualche link da passarmi dove c'è una documentazione anche con esempi sarebbe ottimo...

Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 19 giu 2013 - 13:36

>ottimo ma nn so da dove iniziare mai sentite queste opzioni purtroppo..hai
>qualche link da passarmi dove c'è una documentazione anche con
>esempi sarebbe ottimo...
come prima cosa dovresti prendere tutte le query che coinvolgono gli oggetti che vuoi indicizzare. Dovresti capire come le risorse vengono chiamate (certo, se fai delle SELECT *, scordati quello che ho detto sulle included columns, del resto SELECT * non è da utilizzare). In base all'idea che ti sei fatto, ad esempio tracciando le chiamate che ti arrivano a regime in un lasso di tempo predeterminato, vai a vedere come puoi indicizzare "in generale", mentre per il filtro sull'indice dipende se le letture che fai coinvolgono un subset di dati o meno. Se hai una finestra temporale per cui, ad esempio, i dati sono "online", ecc..

FILTERED INDEX: http://technet.microsoft.com/en-us/library/cc280372.aspx
INCLUDED COLUMNS: http://msdn.microsoft.com/en-us/library/ms190806.aspx
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: mer 19 giu 2013 - 14:36

Ciao Alex,
allora ora sto solamente creando le tabelle del database ed indicizzando i campi che so di certo di utilizzare nelle select. Sapevo che non si deve usare Select *....., poi passerò a creare le stored con all'interno le query e controllerò bene se i campi indicizzati vengono utilizzati. Poi vado a vedere e leggere il link sul filtro dell'indice

ciao e grazie
Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 19 giu 2013 - 15:03

>Ciao Alex,
>allora ora sto solamente creando le tabelle del database ed indicizzando
>i campi che so di certo di utilizzare nelle select. Sapevo che
>non si deve usare Select *....., poi passerò a creare le stored
>con all'interno le query e controllerò bene se i campi indicizzati
>vengono utilizzati. Poi vado a vedere e leggere il link sul filtro
>dell'indice
Ok, volevo farti solo presente che il piano di indicizzazione preventivo è quello che sarà la base da cui partire per fare tuning basato sul tipo di interrogazioni che avrai.
Non è possibile fare quest'analisi a priori, a meno che tu non sappia già alla perfezione come chiamerai la tua base dati. Certo, gli indici implicitamente creati coi vincoli delle PK ci saranno già, ma quelli sulle FK molto potenzialmente cambieranno (e non saranno i soli probabilmente).
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: mer 19 giu 2013 - 15:43

Ok, quindi l'iter iniziale della costruzione degli indici alla costruzione delle tabelle non è sbagliato dato che conosco sicuramente già quali sono i campi da indicizzare, il discorso, come dici te, sarebbe dopo, nel momento della creazione delle query, di creare dei filtri sugli indici Fk, giusto?

Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 19 giu 2013 - 15:51

>Ok, quindi l'iter iniziale della costruzione degli indici alla
>costruzione delle tabelle non è sbagliato dato che conosco sicuramente
>già quali sono i campi da indicizzare, il discorso, come dici
>te, sarebbe dopo, nel momento della creazione delle query, di
>creare dei filtri sugli indici Fk, giusto?
filtrare, fare copertura, cambiare le query all'occorrenza, deframmentare, ricostruire gli indici in manutenzione.. e via discorrendo.
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: mer 19 giu 2013 - 16:06

senti una domanda da perfetto "ignorante" in materia, ma un codice sql di questa tabella:

 Il codice sorgente non è stato renderizzato qui
perchè non c'è sufficiente spazio.
Clicca qui per visualizzarlo in una nuova finestra

non centra nulla con il tema di cui mi stai parlando? A questa tabella mancherebbe cosa?

ciao

Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 19 giu 2013 - 16:32

>non centra nulla con il tema di cui mi stai parlando? A questa tabella mancherebbe cosa?
quelli sono semplici indici nonclustered su campi. Niente di più. Dipende dalle chiamate che fai.
Se su quei campi hai messo FK, ogni join su quei campi trarrà i benefici dell'indice.
Ma i filtered sono da applicare da un altro punto di vista, che è il dominio dei dati che dovrai considerare come fruibili.
Le inclusioni sono per quegli indici la cui chiave è quella usata, diciamo, nelle condizioni di where e on, e la cui foglia copre la selezione degli altri campi della select.
Ma non puoi chiedermi se è corretta, perchè la risposta è: dipende da cosa ci fai.
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: mer 19 giu 2013 - 18:38

>>non centra nulla con il tema di cui mi stai parlando? A questa tabella mancherebbe cosa?
>quelli sono semplici indici nonclustered su campi. Niente di
>più. Dipende dalle chiamate che fai.
>Se su quei campi hai messo FK, ogni join su quei campi trarrà
>i benefici dell'indice.
mi sa che non ho messo la fk sui campi perchè ho semplicemente creato l'indice, come si fa?
>Ma i filtered sono da applicare da un altro punto di vista, che
>è il dominio dei dati che dovrai considerare come fruibili.
>Le inclusioni sono per quegli indici la cui chiave è quella usata,
>diciamo, nelle condizioni di where e on, e la cui foglia copre
>la selezione degli altri campi della select.
>Ma non puoi chiedermi se è corretta, perchè la risposta è: dipende
>da cosa ci fai.

per i filter e le inclusioni mi studio prima i link che mi hai passato e poi semmai ho dei dubbi ti formulo la domanda
>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
>
>http://blogs.dotnethell.it/suxstellino
>http://suxstellino.wordpress.com
>http://mvp.microsoft.com/profiles/Alessandro.Alpi

Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: gio 20 giu 2013 - 07:53

>mi sa che non ho messo la fk sui campi perchè ho semplicemente creato l'indice, come si fa?
la fk serve se hai un legame con un'altra tabella, è una relazione. E si usa il comando ALTER TABLE:
http://msdn.microsoft.com/it-it/library/ms190273(v=sql.100).aspx

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: gio 20 giu 2013 - 14:47

ah ho capito, io per ora non ho impostato le relazioni proprio perchè al 99% conosco i campi da indicizzare ma nel corso del progetto potrebbero variare, pertanto dopo vorrei eseguire la relazione tra tabelle..Domanda ma relazionare le tabelle è più veloce poi eseguire le query?

ho dato una letta alle colonne incluse, leggevo questo: "La manutenzione degli indici può aumentare il tempo necessario per eseguire modifiche, inserimenti, aggiornamenti o eliminazioni nella tabella sottostante o nella vista indicizzata."
Questo se vengono inserite colonne inutili che non verranno utilizzate e comunque solo se avvio la procedura di manutenzione, giusto?
Non mi implica rallentamenti quando eseguo insert o delete o update se le colonne incluse sono giuste ed utilizzate.

Scusa Alex il caldo mi sta dando alla testa :-)...ho un forte dubbio....

se io eseguo un query select in questa maniera:

select
tab1.nome,
tab1.cognome,
tab2.idgruppo,
tab2.nrcomponenti
from tab1
inner join
tab2
on tab1.idstruttura=tab2.idstruttura and tab1.idcliente=tab2.idcliente
where
tab1.idstruttura=1 and tab1.data_arrivo='2013-06-20'

a livello di indici nocluster che di solito creo come ti ho fatto vedere nel precedente post, in base a questo esempio di query dovrei creare per la tab1 un indice per il campo idstruttura un indice per il campo idcliente ed un indice per il campo data_arrivo, quindi 3 indici e quindi stessa logica per la tabella tab2 oppure dovrei creare un indice che racchiude i campi idstruttura, idcliente e data_arrivo, quindi avere solo un indice?

E' un forte dubbio sorry

Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: gio 20 giu 2013 - 15:03

>ah ho capito, io per ora non ho impostato le relazioni proprio
>perchè al 99% conosco i campi da indicizzare ma nel corso del
>progetto potrebbero variare, pertanto dopo vorrei eseguire la
>relazione tra tabelle..
ma cosa centra la relazione con gli indici?? le relazioni vanno fatte se tu ritieni che debbano esserci controlli di integrità referenziale.

Domanda ma relazionare le tabelle è più veloce poi eseguire le query?
La relazione è la relazione, e non ha a che vedere con la velocità delle query. Ogni controllo di vincolo può avere peso sulle performance, ma io mi preoccuperei più di capire se l'integrità referenziale è una cosa che posso sacrificare, ed in molti casi, è meglio di no.

>ho dato una letta alle colonne incluse, leggevo questo: "La manutenzione
>degli indici può aumentare il tempo necessario per eseguire modifiche,
>inserimenti, aggiornamenti o eliminazioni nella tabella sottostante
>o nella vista indicizzata."
>Questo se vengono inserite colonne inutili che non verranno utilizzate
>e comunque solo se avvio la procedura di manutenzione, giusto?
certo, se sono inutili, sono anche inutilmente manutenute.

>Non mi implica rallentamenti quando eseguo insert o delete o
>update se le colonne incluse sono giuste ed utilizzate.
implica eccome, perchè fai più io, perchè devi tenere sincronizzato i valori dell'indice con quelli di tabella, ecc..
però l'implicazione è giustificata dalle performance che prendi in lettura, che in alcuni casi sono veramente migliorative.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: gio 20 giu 2013 - 15:16

Ho capito...

ultima domanda poi approfondisco meglio lo studio in rete:

se io eseguo un query select in questa maniera:

select
tab1.nome,
tab1.cognome,
tab2.idgruppo,
tab2.nrcomponenti
from tab1
inner join
tab2
on tab1.idstruttura=tab2.idstruttura and tab1.idcliente=tab2.idcliente
where
tab1.idstruttura=1 and tab1.data_arrivo='2013-06-20'

a livello di indici nocluster che di solito creo come ti ho fatto vedere nel precedente post, in base a questo esempio di query dovrei creare per la tab1 un indice per il campo idstruttura un indice per il campo idcliente ed un indice per il campo data_arrivo, quindi 3 indici e quindi stessa logica per la tabella tab2 oppure dovrei creare un indice che racchiude i campi idstruttura, idcliente e data_arrivo, quindi avere solo un indice?

E' un forte dubbio sorry

ciao e grazie
Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 24 giu 2013 - 21:34

>a livello di indici nocluster che di solito creo come ti ho fatto
>vedere nel precedente post, in base a questo esempio di query
>dovrei creare per la tab1 un indice per il campo idstruttura
>un indice per il campo idcliente ed un indice per il campo data_arrivo,
>quindi 3 indici e quindi stessa logica per la tabella tab2 oppure
>dovrei creare un indice che racchiude i campi idstruttura, idcliente
>e data_arrivo, quindi avere solo un indice?
senza avere i dovuti monitoring tools sottomano e senza poter interrogare le tue DMV, a prima vista io farei un indice sui campi inclusi nella where/join e poi valuterei se è il caso di includere qualche colonna. Ma non si riesce a fare un buon tuning senza quanto dicevo prima e senza la lettura dei piani di esecuzione.
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: mar 25 giu 2013 - 00:17

Quindi intendi che devo creare un indice ed includere i campi che uso nella where/join...cioè stando all'esempio che ho scritto prima potrei creare un indice in questa maniera:

 Il codice sorgente non è stato renderizzato qui
perchè non c'è sufficiente spazio.
Clicca qui per visualizzarlo in una nuova finestra

così ho messo i due campi della where ed uno della join (ovviamente i campi della tabella tab1) .
Per le colonne le andrei ad aggiungere se mi servono altri campi da controllare, giusto?

Scusa ma perchè è sbagliato creare un indice per ogni singolo campo della where o join?

ciao grazie
Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mar 25 giu 2013 - 19:56

>Quindi intendi che devo creare un indice ed includere i campi
>che uso nella where/join...cioè stando all'esempio che ho scritto
>prima potrei creare un indice in questa maniera:
no, intendo che nella chiave dell'indice metterei quelli che nella tua query sono nella where/join, non INCLUSE.
l'INCLUSIONE è proprio un'altra cosa. Tuttavia l'indice che hai creato può andare, anche se manca di INCLUSIONE, appunto.
Per capire, guarda la CREATE INDEX (http://msdn.microsoft.com/it-it/library/ms188783(v=sql.100).aspx).

>Per le colonne le andrei ad aggiungere se mi servono altri campi da controllare, giusto?
non so cosa intendi, cerca di capire cosa è l'opzione INCLUDE.

>Scusa ma perchè è sbagliato creare un indice per ogni singolo
>campo della where o join?
non è sbagliato, dipende, come già detto, dalla tua situazione. Gli indici vanno controllati sulla tua situazione con un bel piano di monitoring.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: mer 26 giu 2013 - 16:17

Mi sono dato una letta al tuo link ed in modo particolare all'argomento delle colonne incluse.
Prima di tutto in questi giorni ho capito che un buon indice si crea dopo aver creato le query giuste che servono in modo tale da sapere veramente con esattezza i campi che devono essere indicizzati. O sbaglio?
Secondo nell'argomento delle colonne incluse ho letto questo:

"i vantaggi sono:

Possono essere tipi di dati che non sono consentiti come colonne chiave indice.
Non vengono prese in esame dal Motore di database durante il calcolo del numero di colonne chiave indice o della dimensione delle chiavi di indice.

Con un indice con colonne non chiave è possibile aumentare significativamente le prestazioni delle query quando tutte le relative colonne sono incluse nell'indice come colonne chiave o non chiave. I vantaggi nelle prestazioni si ottengono poiché in Query Optimizer è possibile individuare tutti i valori delle colonne all'interno dell'indice. In questo modo, la quantità di operazioni di I/O su disco è inferiore dato che non viene eseguito alcun accesso ai dati delle tabelle o degli indici cluster."
stando a quello che leggo se ho capito bene in creo un indice stabilisco quali sono i campi dell'indice e poi aggiungo i restanti campi come colonne incluse, in modo tale che aumento le prestazioni della query perchè le quantità di operazioni di I/O su disco sono inferiori dato che non vengono eseguiti alcun accessi ai dati delle tabelle o degli indici cluster..
per esempio supponiamo di avere queste tabelle di questo genere:

 Il codice sorgente non è stato renderizzato qui
perchè non c'è sufficiente spazio.
Clicca qui per visualizzarlo in una nuova finestra

e supponiamo che devo eseguire una query del genere:

select 
tab_clienti.cognome,
tab_clienti.nome,
tab_nazioni.descrizione
from tab_clienti
inner join tab_nazioni
on tab_clienti.idstatonazione=tab_nazioni.idnazione
where tab_clienti.idcliente=1

se ho capito bene per creare un buon indice nella tabella "tab_clienti" oltre che ovviamente a creare una relazione tra le due tabelle dovrei scrivere un indice del genere:

 Il codice sorgente non è stato renderizzato qui
perchè non c'è sufficiente spazio.
Clicca qui per visualizzarlo in una nuova finestra

ma se fosse giusto, il campo tab_nazioni.descrizione nell'indice non c'è quindi non viene sfruttato da l'indice stesso.

ciao e grazie
Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: ven 28 giu 2013 - 13:46

>Prima di tutto in questi giorni ho capito che un buon indice si crea dopo aver creato le query giuste che servono in modo
>tale da sapere veramente con esattezza i campi che devono essere indicizzati. O sbaglio?
a parte i principali come quelli fatti sulle PK, poi il fine tuning è quello, sì.

>"i vantaggi sono:
>Possono essere tipi di dati che non sono consentiti come colonne
>chiave indice.
>Non vengono prese in esame dal Motore di database durante il
>calcolo del numero di colonne chiave indice o della dimensione
>delle chiavi di indice.
>
>Con un indice con colonne non chiave è possibile aumentare significativamente
>le prestazioni delle query quando tutte le relative colonne sono
>incluse nell'indice come colonne chiave o non chiave. I vantaggi
>nelle prestazioni si ottengono poiché in Query Optimizer è possibile
>individuare tutti i valori delle colonne all'interno dell'indice.
>In questo modo, la quantità di operazioni di I/O su disco è inferiore
>dato che non viene eseguito alcun accesso ai dati delle tabelle
>o degli indici cluster."
>stando a quello che leggo se ho capito bene in creo un indice
>stabilisco quali sono i campi dell'indice e poi aggiungo i restanti
>campi come colonne incluse, in modo tale che aumento le prestazioni
>della query perchè le quantità di operazioni di I/O su disco
>sono inferiori dato che non vengono eseguiti alcun accessi ai
>dati delle tabelle o degli indici cluster..
se servono, non è obbligatorio, e se l'indice senza inclusione non ti serve, non è necessariamente da fare.. anche perchè le insert e le update poi costano di più, per non parlare dello spazio occupato.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

trinity Profilo | Guru

3.465 messaggi | Data Invio: ven 28 giu 2013 - 16:18

ok grazie ciao
Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

trinity Profilo | Guru

3.465 messaggi | Data Invio: lun 8 lug 2013 - 10:59

Scusa alex,
ricapitolando veloce il discorso indici se dovessi creare un indice corretto senza inclusione basandomi su questa query che posto:

Select
Tab_clienti.idcliente,
Tab_clienti.idtitolo,
Tab_clienti.cognome,
Tab_clienti.nome,
Tab_clienti.sesso,
Tab_clienti.datanascita,
Tab_clienti.codfiscale,
Tab_clienti.indirizzo,
Tab_clienti.telefono,
Tab_clienti.cellulare,
Tab_clienti.fax,
Tab_clienti.email,
Tab_clienti.idcittadinanza,
Tab_clienti.idluogonascita,
Tab_clienti.idluogoresidenza,
Tab_clienti.iddocumento,
Tab_clienti.ndocumento,
Tab_clienti.idluogodocumento,
Tab_clienti.note
From
Tab_clienti
inner join
Tab_movimenti
On Tab_clienti.idstruttura=Tab_movimenti.Idstruttura
Where 
Tab_clienti.idstruttura=@idstruttuta and Tab_movimenti.arrivo=@data1

dovrei creare un indice nella tabella tab_clienti che racchiude i campi: idstruttura e creare un altro indice nella tabella tab_movimenti che racchiude i campi: idstruttura e arrivo e non singoli indici per le singole colonne usate nella where e join, giusto?

Ciao
Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 8 lug 2013 - 14:41

>dovrei creare un indice nella tabella tab_clienti che racchiude
>i campi: idstruttura e creare un altro indice nella tabella tab_movimenti
>che racchiude i campi: idstruttura e arrivo e non singoli indici
>per le singole colonne usate nella where e join, giusto?
non ti posso rispondere con certezza perchè, e ripeto, dipende dalla tua situazione.
Devi tracciare le chiamate che ricevi, che piani vengono proposti, controllare le DMV (missing indexes) e vedere qual è l'indice migliore in base all'analisi.
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !