Clustered composite key high fragmentation and fill factor

Question

I've recently made a table to hold the language preferences of my users as follow:

CREATE TABLE [dbo].[systemUserLangPreference](
  [systemUserID] [int] NOT NULL,
  [langID] [int] NOT NULL,
  [preferredOrder] [int] NOT NULL,
  [createdBy] [int] NOT NULL,
  [createdOn] [datetime] NOT NULL,
  [lastActionBy] [int] NOT NULL,
  [lastActionOn] [datetime] NOT NULL,
CONSTRAINT [PK_systemUserLangPreference] PRIMARY KEY CLUSTERED 
([systemUserID] ASC, [langID] ASC)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
 ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
) ON [PRIMARY]

There's less than 1,000 rows in there now so performance isn't much of an issue at this time however when I run an index fragmentation report this index and more of my compound keys always comes up as high fragmentation no matter what I do.

Using

SELECT ps.database_id, ps.OBJECT_ID,
ps.index_id, b.name,
ps.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS ps
INNER JOIN sys.indexes AS b ON ps.OBJECT_ID = b.OBJECT_ID
AND ps.index_id = b.index_id
WHERE ps.database_id = DB_ID()

This one index will return 80% avg fragmentation even moment after I rebuild it. I've tried playing with the fill factor with the following results:

Fill 100%; Fragmentation 75%
Fill 80%; Fragmentation 80%
Fill 50%; Fragmentation 62.5%
Fill 10%; Fragmentation 19.44%
Fill 1%; Fragmentation 1.90%

So it seems the lower I go the better? I'm not sure I'm interpreting this right. Since the table is mostly reads (insert on new user and I guess when they learn a language) wouldn't a higher fill factor be better? Why does it lead to immediate fragmentation and is it a bad thing?

Answer 1

对于非常小的表，碎片不仅无关紧要，而且几乎无法控制。前八页是从混合区中分配的，这些区几乎总是不连续的。只有在索引超过 8 个页面后，才会从统一区分配额外的页面。

在少于 1,000 行时，您的聚集索引将远低于 64K，并且完全从混合区分配（除非您开始通过调整填充因子来强制问题，如您所见）。

您可以通过发出以下命令了解如何分配此聚集索引的页面：

DBCC EXTENTINFO( DB_NAME, systemUserLangPreference, PK_systemUserLangPreference)

一旦索引足够大以至于分配的页数超过 8 个，您就可以通过删除索引然后重新创建索引来确保它们都分配在统一区之外。不过，同样，对于如此小的表，碎片不会对性能产生影响，您可能不应该尝试通过摆弄填充因子来解决它。

降低填充因子实际上可能会产生不利的结果，因为每个页面上的记录较少，因此需要将更多页面加载到内存中。 这里有更多关于为什么要小心填充因子的信息。

有关页面和范围的更多详细信息，请参阅此文章。