Why would you do anything through the SSMS GUI???
Try doing it as a pro, by a script. Your best option is to create the index online with drop existing, changing the definition to match the new desired schema in the process:
create index ... on ... include ... with (online = on, drop_existing = on);
This, obviously, is subject to the usual restrictions for ONLINE operations, and will cause the normal overhead caused by an ONLINE index create/rebuild operation. But the good news is that the operation will be online, will not block existing queries and the old index will be available for queries while the new one is being built. There will be a query drain stage at the end when all queries will block while the indexes are being swapped, but that should be a very fast operation (as long as there are not long running user transactions blocking the swap itself).
Based on your question, I would index the Timestamp
column with the clustered index. And to make the index unique, just make sure to include the identity column in the index definition:
... PRIMARY KEY CLUSTERED ([Timestamp], [Id])
If query performance for queries on Exchange_Id
is still an issue after that, you can also add a non-clustered index that looks something like this:
UNIQUE INDEX ([Exchange_Id], [Timestamp], [Id])
.. but if you do, consider including any columns that the query may need, in order to create what's known as a covering index.
UNIQUE INDEX ([Exchange_Id], [Timestamp], [Id]) INCLUDE ([Type], [Amount], [Price])
Remember that there's a disk space issue involved as well, as you stated that your table contains a large number of rows. The clustered index will not change the amount of disk space your table consumes either way, but adding a non-clustered index will allocate extra space. If you INCLUDE
all the columns from your table, like I did in the example, the non-clustered index will roughly take up as much space as the rest of the table does.
Best Answer
I was fighting a similar problem today with some slow SQL queries generated by WooCommerce in WordPress and I managed to resolve the issue by creating the following two indexes:
In my case, however, the query was always looking for IDs in the longtext field:
That is why the index works in my case for my specific queries. I hope this helps you :)
Edit: You may also check the following question I posted today and I managed to optimize my query by adding indexes:
How to optimize this specific MySQL query which examines 2.84M rows and 29.49k InnoDB distinct pages