I might not be framing this question correctly. By use, I don't mean where and when should I create one on a table - that would be an overly broad question.
What I mean is once I create a clustered index, does it improve performance in general or do I need to use the associated column in queries to get the performance boost?
Here's an example: Suppose I create a table with the following columns; RowNum, FileId, Name, and Date. RowNum I create as an identity column and I apply a clustered index. However, in practice the table is generally queried using FileId. For example:
SELECT
FileId,
Name
FROM MyTable
WHERE FileId IN ('11101101', '11101201', '11101301')
Since the RowNum is not used in the query, do I still get any performance benefit from the index?
I've been reading up on constraints and indexes and I want to be certain I understand them. This seems to be a point that is glossed over in everything I read.
Edit: I think I've got my answer. Or at least as close to a clear-cut answer as I'm going to get.
Let me restate the question a little: What I was trying to sort out is suppose I have a table that has three columns, rowNum, Id, and Name. This table will generally be queried on Id or Name, and let's go one step further and say that we will have nonclustered indexes on each of those columns. My question was, under this scenario, does a clustered index on rowNum improve the performance of the queries that use the other columns.
As best I can gather, the answer is yes, but you might want to consider putting the clustered index on another column.
Short answer is that you need to have 1! clustered index for each table, and it is often the PK. THe PK is the right candidate if it is counter (meaning new rows will go at the end of the table). There are plenty of discussions on SO (like this one)and on the net about this.