主键和索引-查询性能

Question

I have a table which contains over 1 million records. There are no keys defined on the table. However we do have clustered and non-clustered index defined.

I want to know if there will be actually a performance improvement when I do a SELECT query and include the columns where we have index created in the WHERE clause?

Is having primary / unique key a must to leverage the true benefits of Indexes?

Table details:

• 260 columns
• No Keys
• No identity column defined.
• No rowguidcol column defined.
• 1 clustered index and 1 non clustered index

Query:

select * 
from employee(nolock)
where employeeID = '15' and employeeType = 'FT' 

Answer 1

Personally based on my experience the clustered index is best when it's narrow, unique and non-changing. The smaller the clustered key (non-unique clustered indexes add a 4 byte "uniquifier") the better because it creates a denser leaf page on the subsequent non-clustered indexes.

Assuming you currently have a non-unique clustered index on an integer (assuming employeeID is an integer), then the size of each key is effectively doubled do to the uniquifier (4 from the integer and 4 from the uniquifier).

The difference between a non-unique/unique clustered index would be the non-clustered leaf rows fitting, respectively, 1000 and 2000 rows to a page. A denser non-clustered leaf page means traversing the index levels faster as well as saving on disk space (1000000 rows at 4byte saved a row amounts to roughly 3 gigs per non-clustered index).

A lot of this is based on assumptions on your table.

TLDR: A narrow clustered index key is best; make it a primary key to enforce uniqueness and prevent a wasteful 4byte uniquifier.