What is Fill Factor?

When dealing with index design in SQL Server one of the single most important things to configure is the fill factor.  The fill factor is a number between 0-100 which indicates how full (percentage-wise) each page of the index should be when the index is created.  This setting also comes into play when an index is rebuilt or reorganized (defragmented).  A fill factor of 0 is functionally the same as a fill factor of 100.

Impact on Disk Space

The higher the fill factor, the more full each page of the index is once it’s created.  That means fewer pages are required to store the same amount of information.  As the fill factor drops, the number of pages required increases as each page is not as full.  The chart below shows the impact of different fill factors on a sample index.

As you can see, the index grows at a logarithmic rate.  So, generally speaking, the difference in space consumption between say a fill factor of 90 and 100 is negligible.  The difference between 80 and 90 is possibly tolerable but fill factors lower than 80 quickly balloon the index wasting considerable space on disk.

Impact on Memory Space

When SQL Server need data from an index or a heap, it reads that data from the disk and then stores that data in memory.  SQL Server will then try to keep that data in memory as long as possible to avoid having to read it from disk again.  The catch is that SQL Server reads data into memory in pages which means they will maintain the same distribution that they have on disk.  So, wasted space on disk equals wasted space in memory.

Data Warehouses and Fill Factor

The lower the fill factor, the more reads will be required to access the same information.  For data that is very “read-centric”, this can be a problem.  For example in data warehouses, data is written once and read many times.  Individual records rarely change in a data warehouse and so assuming there is a solid partitioning plan in place, setting a fill factor of 100 is *generally* a good idea.

OLTP Databases and Fill Factor

OLTP databases usually have a high number of reads and writes so balance is key.  Obviously, the fill factor should be high enough to minimize the number of reads to access any specific record, however if it is too high performance can be negatively impacted by page splits.  Data in SQL Server is stored in B-trees.  When a record is inserted into an index, SQL Server will start at the root, traverse the tree to the page where the record belongs and if there is adequate free space, insert the record into that page.  If SQL Server reaches that page and there is not enough room, SQL Server will perform the following:

1. Create a new page
2. Make an entry into the parent node pointing to the newly created page
3. Split the original target page in half (hence the “page split”)
4. Move 1/2 of the rows to the new page

As  you can see, this can be quite an expensive operation – especially if the parent node is also full.  If the parent node is also full, the same operation takes place and so on up the tree.

So, if the fill factor is set to 100 on an index that receives frequent inserts, there will be a negative impact on write performance.  Generally speaking, setting the fill factor to 90 and then either directly monitoring the number of page splits using Extended Events or indirectly monitoring page splits by analyzing page density the fill factor can be adjusted up or down.  If the index is receiving a lot of page splits or page density is changing dramatically, consider lowering the fill factor.  If there are few to no page splits, consider raising the fill factor.  Just keep in mind that changing between 90 and 95 will have little impact, but 80 to 90 may have a noticeable impact (see graph above).

PAD_INDEX option

One more thing to point out about fill factor is the PAD_INDEX setting.  When specifying a fill factor, the PAD_INDEX option can be turned on which will force SQL Server to apply the same fill factor to the intermediate nodes of the B-tree.  By default this option is turned off.