Timeline for Help with indexing narrow table with many millions of rows
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 26, 2014 at 20:39 | vote | accept | Amberite | ||
| Nov 26, 2014 at 19:43 | comment | added | Daniel Hutmacher | Not sure if you would see any large benefits from creating multiple filtered indexes. What you're suggesting is an alternative to partitioning, though. Try it with the non-clustered index if you have the time and an Enterprise Edition license. | |
| Nov 26, 2014 at 19:41 | comment | added | Daniel Hutmacher | Ascending/descending won't matter on Exchange_Id and Timestamp. I would order Id ascending, though. | |
| Nov 26, 2014 at 19:17 | comment | added | Amberite | One more question - since we have a fixed number of Exchanges in the system, should I maybe create a new UNIQUE INDEX for each Exchange? In other words, create a UNIQUE INDEX with a WHERE [Exchange_Id] = <Id>? This should improve index speeds further, right? | |
| Nov 26, 2014 at 19:13 | comment | added | Amberite | Thanks so much! This is exactly the kind of information I was hoping to learn. For the PRIMARY KEY CLUSTERED index, should the [TimeStamp] and [Id] columns be sorted ASC? Or will the sorting not matter? | |
| Nov 26, 2014 at 18:47 | history | answered | Daniel Hutmacher | CC BY-SA 3.0 |