Salve, ho un problema con degli indici su una tabella di SQL Server 2005.
Può essere che io stia facendo una domanda stupida ma purtroppo al momento non ne conosco la risposta

Ho una tabella Prodotti con qualche migliaio di record ed un indice nonclustered sulla colonna Categoria (di tipo varchar, chiave esterna alla tabella delle categorie)

Visualizzando il piano d'esecuzione di una semplice istruzione

SELECT * FROM Prodotto WHERE Categoria='xxx'

SQL Server utilizza un clustered index scan, non utilizzando l'indice che gli ho creato.

Sapete dirmi quale può essere il motivo?

Grazie

Perfetto, ti ringrazio. Avevo già letto vari articoli che parlano di indici ma questa tua risposta devo dire è stata la più chiara.

nicholasp ha scritto:

Mi sapresti anche suggerire un modo di rendere più efficiente la ricerca in questo caso?

Solo (ma solo) se la chiave dell'indice è un varchar di pochi caratteri puoi pensare di rendere l'indice un indice di copertura per quella query. Un indice di copertura è un indice (di tipo non clustered) che al suo livello foglia ha TUTTI gli elementi per risolvere la query. Come ti ho detto nel precedente post, la livello foglia di un indice non clustered trovi il puntatore, rappresentato dalla chiave dell'indice clustered, per arrivare alla pagina dati. Se tutti i campi richiesti dalla query fossero presenti a questo livello non vi sarebbe alcuna ragione per accedere, tramite l'indice clustered, lla pagina dati. Immagina una query simile a

SELECT campo1, campo2, campo3
FROM dbo.MyTable
WHERE campo4 = 'xyz'

supponi che l'indice clustered sia su campo1 e l'indice non clustered sia campo4. Se aggiungi campo2 e campo3 alla definizione dell'indice su campo4 ecco li che tutti i campi utilizzati dalla query sono presenti al livello foglia dell'indice non clustered. Fino a SQL Server 2000 l'unico modo per fare ciò era rappresentato dal creare l'indice non clustered composto dai campi campo2+campo3+campo4 (secondo l'ordine che avresti ritenuto più appropriato). Questo però significava gravare l'indice con una chiave MOLTO più onerosa; in SQL Server 2005 è stata introdotta la possibilità di aggiungere dei campi SOLO al livello foglia di un indice non clustered (clausola INCLUDE). In questo modo potresti continuare ad avere l'indice non clustered sul campo4 ma puoi aggiungere (INCLUDE) campo2 e campo3 nella definizione dell'indice. In questo modo non vai a gravare sull'intera struttura ma solo sul livello foglia; il numero dei livelli b-tree rimane invariato ma il livello foglia sarà per forza di cose più vasto.
Nel tuo caso dove hai specificato il carattere [*] nella select list significa che dovresti includere tutti i campi della tabella (ad eccezione di quelli contenuti nella definizione dell'indice clustered) nella clausola include affinchè quello possa diventare un indice di copertura. Questo è uno solo dei tanti motivi per i quali è bene non utilizzare mai il carattere [*], ma se quelli che ti servono sono solo un sottoinsieme dei campi della tabella (e nel 99% dei casi è così) specificare nella select list i campi necessari contribuisce a creare query efficienti che potrebbero avvalersi (magari a tua insaputa) della presenza di un indice di copertura che, come ti sarai reso conto dalla mia spiegazione, rappresentano un benefit non indifferente quando utilizzabili. Ogni campo "superfluo" che chiedi che venga estratto ci mette del suo per limitare questa possibilità...

Bye