Skip to main content

Your first column in the index is cl_totalcrawltimes. In the WHERE clause you're using this column to define a lower range (cl_totalcrawltimes > 0).

Depending on the data distribution this most probably will lead to an index scan instead of an index seek. Furthermore, cl_crawlsource is not part of the index (the include section, preferrably), so this would require a clustered index key lookup anyway.

Therefore, SQL Server ignores the index since it seems to be more efficient to perform a clustered index scan.

Find the column with the most selective values for your query andFor best results, make thatthose columns on which you query for an exact match the first columncolumns of your nonclustered index. Remove cl_LastProcessDate since it isn't used anywhere in the query (it's not relevant toWhether the next column should be used in ORDER BY since this operation is performed after all data are collected)your inequality column or your order by column depends on what the optimizer likes, if any.)

Your first column in the index is cl_totalcrawltimes. In the WHERE clause you're using this column to define a lower range (cl_totalcrawltimes > 0).

Depending on the data distribution this most probably will lead to an index scan instead of an index seek. Furthermore, cl_crawlsource is not part of the index (the include section, preferrably), so this would require a clustered index key lookup anyway.

Therefore, SQL Server ignores the index since it seems to be more efficient to perform a clustered index scan.

Find the column with the most selective values for your query and make that the first column of your nonclustered index. Remove cl_LastProcessDate since it isn't used anywhere in the query (it's not relevant to be used in ORDER BY since this operation is performed after all data are collected).

Your first column in the index is cl_totalcrawltimes. In the WHERE clause you're using this column to define a lower range (cl_totalcrawltimes > 0).

Depending on the data distribution this most probably will lead to an index scan instead of an index seek. Furthermore, cl_crawlsource is not part of the index (the include section, preferrably), so this would require a clustered index key lookup anyway.

Therefore, SQL Server ignores the index since it seems to be more efficient to perform a clustered index scan.

For best results, make those columns on which you query for an exact match the first columns of your nonclustered index. (Whether the next column should be your inequality column or your order by column depends on what the optimizer likes, if any.)

Source Link
Lmu92
  • 396
  • 1
  • 4

Your first column in the index is cl_totalcrawltimes. In the WHERE clause you're using this column to define a lower range (cl_totalcrawltimes > 0).

Depending on the data distribution this most probably will lead to an index scan instead of an index seek. Furthermore, cl_crawlsource is not part of the index (the include section, preferrably), so this would require a clustered index key lookup anyway.

Therefore, SQL Server ignores the index since it seems to be more efficient to perform a clustered index scan.

Find the column with the most selective values for your query and make that the first column of your nonclustered index. Remove cl_LastProcessDate since it isn't used anywhere in the query (it's not relevant to be used in ORDER BY since this operation is performed after all data are collected).