When you have a clustered index on a table, the clustered index IS the table!
Mentally you can substitute "table" for "clustered index" in this instance and it will make sense.
The data for every field in every row is in your clustered index. The clustered index just sets the order of the physical pages in the database to be organized by your clustering key(s).
You can always fall back on the phone book analogy for these things, too: in your classic phone book, the data is clustered on Last Name, First Name
. Each entry still has PhoneNum, Address
at the leaf level but you don't order by that. The pages are in physical order by the the keys.
I can't advise on optimizing the query unless you show us the table and query you are running, but basically this cost will be paid one way or another. If you don't update the clustered index it will be a table update and a table scan.
That's a great question.
And there are good answers.
The engine definitely will use the index even if you don't use every key column.
That's especially so if they are in order, as you are talking about.
(can anyone else speak to different orders of key columns?)
You will benefit just fine from selecting just on the first column alone as a key, or multiple columns.
What will make a difference - for any index - is staying inside the INCLUDEd columns.
No matter how many key columns you use in your Where, the performance hit for having to go back to the primary key for additional columns can be huge as it doubles the "operations".
When it comes to dealing with performance vs. size, you have the same problem as with any index.
Since you know you want the same columns returned in all cases, if you are READ focused, you will probably want to the index with all 6, if you INCLUDE everything.
It will certainly save you db size compared to making both indexes.
On WRITE, you obviously have a bigger burden with a larger index. That is a significant additional amount of sorting.
If you do just one row inserted at a time, maybe it won't hardly matter at all.
If you do bulk inserts, you'll definitely want to test the two indexes to see the write performance for your actual inserts.
Best Answer
In there interest of showing a generalized example until we see your particular DDL and query, take the below as a basic example:
So we have a test table, SomeTable, with a clustered index. Execute the below query:
This causes a Clustered Index Scan, like you are seeing:
So analyzing the query, we have the column AnotherInt that is in the
WHERE
clause and being searched on. We are also retrieving the SomeData column, so to prevent a key lookup in the clustered index (or the optimizer may even just use a Clustered Index Scan again), we'll have SomeData as anINCLUDE
column:Now, executing the same query above:
SQL Server will utilize that non-clustered index to return the data. It is a covering index, because it won't need to do a lookup on the clustered index for the remaining data:
Through creating a prudent NCI, we have now eliminated the CI Scan in lieu of an Index Seek.