Difference in performance between clustered and non-clustered indexes - sql-server

Question

I found a table in DB with two separate indexes over the same column. The column type is int and there is a clustered primary key on this column. In addition to this, there is a unique non-clustered index on the same column. Indexes have the same options (sort direction and others) and don't contain any included columns.
This index is used by foreign key constraints in some other tables, thus I can't drop it without recreating foreign key constraints.
Could be any sane reason for this?

Answer 1

Maybe it is for efficiency. The nonclustered index is normally smaller than the clustered index, because the clustered index at the leaf level contains all the (non-LOB) fields. So maybe it prefers to use the nonclustered index to enforce the foreign key constraints.
Update: I have done some further tests using AdventureWorks database, which bear out this theory. See below.
I can reproduce the problem using two tables T1 and T2. T1 is the parent and there is a foreign key relationship from T2 to T1.
When T1 has a clustered primary key constraint and a nonclustered unique index Ix-T1, I can alter the table and drop the clustered primary key constraint, but I can't drop Ix-T1 as you found.
If I make T1 with a nonclustered primary key constraint and a clustered unique index Ix_T1, then the situation is reversed: I can drop Ix-T1, but I can't remove the primary key constraint.
CREATE TABLE T1
(
id int NOT NULL CONSTRAINT PK_T1 PRIMARY KEY CLUSTERED
);
CREATE UNIQUE NONCLUSTERED INDEX Ix_T1
ON T1(id);
CREATE TABLE T2
(
id2 int NOT NULL PRIMARY KEY CLUSTERED,
id1 int NOT NULL FOREIGN KEY REFERENCES dbo.T1(id)
);
INSERT INTO T1 (id)
VALUES (1), (2), (3), (4);
INSERT INTO T2 (id2, id1)
VALUES (11, 1), (12, 2), (13, 3);
Try to drop the nonclustered index. This fails.
DROP INDEX Ix_T1
ON dbo.T1;
However I can drop the clustered primary key constraint.
ALTER TABLE dbo.T1
DROP CONSTRAINT PK_T1;
Repeat the test with T1 having a nonclustered primary key and a clustered unique index.
CREATE TABLE T1
(
id int NOT NULL CONSTRAINT PK_T1 PRIMARY KEY NONCLUSTERED
);
CREATE UNIQUE CLUSTERED INDEX Ix_T1
ON T1(id);
This time, I cannot drop the primary key constraint.
ALTER TABLE dbo.T1
DROP CONSTRAINT PK_T1;
However I can drop the clustered index.
DROP INDEX Ix_T1
ON dbo.T1;
So, if my theory is correct, the performance could suffer if you remove the nonclustered index. You might want to do some investigation and tests.
Is there any documentation for the database schema explaining why the index exists? Or can you ask the person who designed the database?
I've done some further tests using AdventureWorks2014, which bear out my theory.
USE AdventureWorks2014;
GO
CREATE SCHEMA test;
GO
-- Create two test tables
SELECT *
INTO test.SalesOrderHeader
FROM Sales.SalesOrderHeader;
SELECT *
INTO test.SalesOrderDetail
FROM Sales.SalesOrderDetail;
-- Test 1 - Clustered primary key and nonclustered index
ALTER TABLE test.SalesOrderHeader
ADD CONSTRAINT PK_Test_SalesOrderHeader PRIMARY KEY CLUSTERED (SalesOrderID);
CREATE UNIQUE NONCLUSTERED INDEX Ix_Test_SalesOrderHeader
ON test.SalesOrderHeader(SalesOrderID);
-- Test 2 - Nonclustered primary key and clustered index
CREATE UNIQUE CLUSTERED INDEX Ix_Test_SalesOrderHeader
ON test.SalesOrderHeader(SalesOrderID);
ALTER TABLE test.SalesOrderHeader
ADD CONSTRAINT PK_Test_SalesOrderHeader PRIMARY KEY NONCLUSTERED (SalesOrderID);
-- Test 3 - Clustered primary key only
ALTER TABLE test.SalesOrderHeader
ADD CONSTRAINT PK_Test_SalesOrderHeader PRIMARY KEY CLUSTERED (SalesOrderID);
-- Same for all tests
ALTER TABLE test.SalesOrderDetail
ADD CONSTRAINT PK_Test_SalesOrderDetail PRIMARY KEY CLUSTERED (SalesOrderDetailID);
ALTER TABLE test.SalesOrderDetail
ADD CONSTRAINT FK_Test_SalesOrderDetail_SalesOrderHeader FOREIGN KEY (SalesOrderID) REFERENCES test.SalesOrderHeader(SalesOrderID);
-- Update 100 records in SalesOrderDetail
UPDATE test.SalesOrderDetail
SET SalesOrderID = SalesOrderID + 1
WHERE SalesOrderDetailID BETWEEN 57800 AND 57899;
Actual execution plan for test 1.
Actual execution plan for test 2. The estimated subtree cost for the Index Seek operator is almost identical to test 1.
Actual execution plan for test 3. The estimated subtree cost for the Index Seek is more than double test 1 or test 2.
And here is a query that measures the sizes of the indexes. (Test 1 configuration.) You can clearly see that the clustered index is much bigger.
-- Measure sizes of indexes
SELECT I.object_id, I.name, I.index_id, I.[type], I.[type_desc], SUM(s.used_page_count) * 8 AS 'IndexSizeKB'
FROM sys.indexes AS I
INNER JOIN sys.dm_db_partition_stats AS S
ON S.[object_id] = I.[object_id] AND S.index_id = I.index_id
WHERE I.[object_id] = OBJECT_ID('test.SalesOrderHeader')
GROUP BY I.object_id, I.name, I.index_id, I.[type], I.[type_desc];
Here are some references that explain clustered indexes and nonclustered indexes.
TechNet > Tables and Index Data Structures Architecture: https://technet.microsoft.com/en-us/library/ms180978(v=sql.105).aspx
Training kit 70-462 Administering Microsoft SQL Server 2012 Databases > Chapter 10: Indexes and Concurrency > Lesson 1: Implementing and Maintaining Indexes
Microsoft SQL Server 2012 Internals by Kalen Delaney > Chapter 7: Indexes: internals and management