聚集和非聚集索引大数据插入

Question

I had a clustered index on 5 keys (columns). I had an unclustered index on 2 columns. Because I'm inserting 2-3 million rows in one run, I changed the 2 column unclustered index to clustered and changed the 5 column clustered index to 5 column unclustered index. My question.

1. When making an index clustered (basically delete and recreate the index as clustered ), I don't need the include (any columns) right since this is clustered?

2. Is it generally correct that I switch the less column index into clustered and change the large column clustered index to unclustered? In other words, clustered index should be simple and small?

3. Is there any performance issues if I switch these two indexes?

Answer 1

Unless it's a link table, you normally have clustered index on 1 column. And a general recommendation is to choose the smallest possible type for clustered index column(surely which fits your requirements). Having many columns not only increases size ( each non-clustered index stores value of clustered index [includes clustered index]! ), but also greatly increases chances of external fragmentation and degrading performance even of inserts . Thus, my answers to your questions.

1. That's correct, clustered index is a table, no need to include any columns
2. Yes, absolutely
3. I'm not sure what if you are asking about performance of switching itself or performance impact of having smaller(or fewer columns) clustered index, so I'll try to answer both.
   • Switching itself. When you switch clustered index to non-clustered, I believe it should not be expensive (I don't think the engine will actually shuffle blocks and extents to make heap). Definitely IAM has to be changed which will take time. Changing non-clustered index to clustered involves much more activity. In addition to moving data according to clustered index key, SQLServer has to update all non-clustered indexes.
   • Further impact (quite a large topic, I put a very short answer)... Smaller clustered index means less space needed for storing all other indexes which in turn means faster access to data and less resource consumption by the engine.

Update I realized (thanks to Aaron Bertrand for pointing that out) I made quite vague statement regarding inclusion of clustered index to non-clustered indexes. To be absolutely correct, each non-clustered index includes row locator which points to row. When table is clustered, row locator is the clustered index key. More info regarding clustered indexes: [1] , [2] .