Ambii indecşi pot fi utili, la query-uri diferite. Mai precis, indexul nonclustered e util când faci o căutare după coloana datetime, fără sa ai nicio condiţie pe coloana int. Să luăm ca exemplu tabela Production.ProductCostHistory din AdventureWorks şi următoarele trei query-uri:
SELECT COUNT(*) FROM Production.ProductCostHistory WHERE ProductID=708
SELECT COUNT(*) FROM Production.ProductCostHistory WHERE StartDate='20010701'
SELECT MAX(StartDate) FROM Production.ProductCostHistory
Pentru primul query se face Clustered Index Seek (şi are un cost total de 0.0032876), însă pentru al doilea query se face Clustered Index Scan (având un cost total de 0.0053128), pentru că avem nu avem condiţie pe prima coloană din index, iar pentru al treilea query face tot un Clustered Index Scan (costul fiind de 0.0054355). Dacă creăm şi un index non-clustered, pe aceleaşi coloane ca şi indexul clustered, dar în ordine inversă:
CREATE INDEX IX ON Production.ProductCostHistory (StartDate, ProductID)
Atunci şi al doilea query foloseşte un index seek, având astfel o performanţă mai bună (costul este acum 0.0034049). La al treilea query, aparent se face un Index Scan (pe noul index), dar observăm că de fapt e limitat cu un TOP 1, ceea ce îl face să fie la fel de performat ca un seek (costul total fiind 0.0032843).
Deci în cazul tău, problema se rezumă la a decide dacă pot exista query-uri care să pună condiţie doar pe coloana datetime, fără implica şi coloana int. Dacă există, atunci trebuie pus în balanţă beneficiul rezultat la asemenea interogări cu costul actualizării unui index suplimentar la adăugarea/actualizarea/ştergerea datelor din tabele. În cazul în care interogările sunt mult mai dese decât modificările, atunci probabil e mai bine să păstrăm indexul. Dacă modificările sunt foarte dese, atunci poate ar fi mai bine să renunţăm la el (dar chiar şi modificările pot beneficia de un index în cazul în care avem un UPDATE sau un DELETE care are o condiţie care implică acele coloane).
Răzvan