Timeline for Index included columns
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 28, 2013 at 16:24 | vote | accept | Barguast | ||
| Jan 27, 2013 at 1:03 | history | tweeted | twitter.com/#!/StackDBAs/status/295336294454800384 | ||
| Jan 27, 2013 at 0:45 | answer | added | Paul White♦ | timeline score: 5 | |
| Jan 26, 2013 at 19:32 | history | migrated | from stackoverflow.com (revisions) | ||
| Jan 26, 2013 at 11:32 | answer | added | Remus Rusanu | timeline score: 5 | |
| Jan 26, 2013 at 11:18 | comment | added | Barguast | @marc_s - Yes, it is the ID column that's the clustered index. Odd that SQL suggested it, if it's unnecessary? | |
| Jan 26, 2013 at 11:17 | comment | added | Barguast | @ta.speot.is - I only ever insert and select from this table. I don't update or delete. | |
| Jan 26, 2013 at 11:06 | comment | added | marc_s |
You are correct in your understanding of how the index and included columns work. One side-note: the clustering key of your table (I'm assuming this could be the ID column) is automatically part of every nonclustered index - so you really don't need to specify that again yourself in the list of included columns
|
|
| Jan 26, 2013 at 11:04 | comment | added | ta.speot.is |
There's a difference, in your query SQL Server has to do much more work when inserting, updating and deleting data because it has to order by three columns instead of one. Timestamp by itself might be selective enough to filter out 90% of the results, how much data do you change?
|
|
| Jan 26, 2013 at 11:03 | history | asked | Barguast | CC BY-SA 3.0 |