Microsoft recommends that you create a clustered index for each table. However, due to the ease of use of sqlserver, many people do not know clustering indexes and non-clustered indexes, therefore, if sqlserver does not create a clustered index on the primary key, most of the tables may be in a heap structure, and the heap structure is stored in disorder, which makes retrieval inconvenient and the space is not easy to manage, therefore, Microsoft has made a tough move. If a colleague who does not create a table creates a clustered index, sqlserver will automatically create a clustered index on the primary key.
In fact, most of the information on the Internet does not recommend that clustered indexes be built on the primary key. This is a waste because clustered index queries are faster, it should be set up on columns that frequently query and have the same attribute value (such as classification). This is like the past.
However, as far as I have processed data (hundreds of millions of data records), there is no sufficient evidence that clustering has obvious advantages in non-primary keys, because the query of a table is not only a clustered index query, but also involves other queries. The indexes of other queries depend on the clustered index to find data. Besides, the table also has insert, update, each delete operation may involve clustered indexes. If the primary key is not a clustered index, insert a record, update, and delete. to modify a record through a primary key, you may need to take two steps. Step 1, first find the primary key, then find the clustered index through the primary key, and finally find the data. If the primary key is a clustered index, these operations only need one step.
Of course, this is only my own analysis, not necessarily true.