Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a large table which has a clustered index with an identity primary key. I'm deciding on the correct value for the fill factor for this table to minimise page splits. We maintain indexes using a script run daily which measures fragmentation and takes appropriate action. The table contains variable length columns.

My first thought was to set it at 100 (as records should only be written to then end of the table) but I assume that changes to the variable length columns could also cause page splits, so I'm now veering towards 90.

Any advice appreciated.

share|improve this question
up vote 6 down vote accepted

It Depends

It's a balancing act. If your table is read intensive, with not many updates or deletes then the default (which is 100) should be ok.

If your table is very write intensive, with lots of updates, then a value below 80 might be more appropriate.

There's no magic formula for this stuff. (AFAIK, if there is please let me know) Best thing to do is have a test environment, have some workload to test. Make the changes & see how your database performs with the workload.

share|improve this answer

Nick's pretty much correct.

If you do updates that increase the size of a record on packed pages, then you'll cause page splits, but apart from that, with an identity primary key nothing's going to cause page splits in the clustered index.

(Although saying that, there are 5 types of page splits that the Storage Engine can do, and not all of them cause fragmentation and data movement - the one you get when inserting monatonically increasing identity values is a end-of-page split. But I digress...)

I've helped many customers with this and I wrote the BOL around it all - if you want to just pick a value as the stake-in-the-ground, 70% has seen the most success. As Nick says, monitor and tweak as appropriate.

Picking a fillfactor for any index is a balancing act of how much activity occurs that pushes the page fullness towards 100% and how often you can take corrective action to reset the fillfactor. You need to think about how much space will initially be 'wasted' on the pages if you set the fillfactor really low, like 50%, but again I've seen this be appropriate in some cases.

You should also consider how the index will be used. If it's just for singleton lookups, you might get away with a lower fillfactor and more time between rebuild/defrag as you're not going to waste too many IOs/memory from having a lot of the sparsely populated clustered index in memory. For doing large range scans, you'd want to have the fillfactor a bit higher, to increase the IO and memory efficiency.

There's also the OLTP vs DW question - usually a DW is unchanging so the indexes would have 100% fillfactor. OLTP is the hard part.

After you've sorted out the clustered index, remember that the nonclustereds will need attention too as they most likely will get fragmented.

When reseting the fillfactor, remember you have a choice between rebuilding and defragging. DBCC INDEXDEFRAG/ALTER INDEX ... REORGANIZE can reset the fillfactor in some cases for indexes that aren't badly fragmented.

Hope this helps!

(Sorry for the 'over-answer' - one of my hot-buttons, having written the code :-)

share|improve this answer
Paul, Great answer! +1 Thanks. – Alan Jun 6 '09 at 17:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.