The clustered index of a table determines the order in which actual records are stored. This means that with a random GUIDs column as a clustered index you inse

The clustered index of a table determines the order in which actual records are stored. This means that with a random GUIDs column as a clustered index you insert records in random places of the table, while with the two other options you append records at the end - no surprise this is much faster. Now, the table is not just sequentially written records, they are actually organized as some b-tree variant. Still, appending to a b-tree is a faster operation than inserting in the middle. Rebuilding the index (actually the table) with a FILLFACTOR parameter makes space in each b-tree node so that new records don't cause too much reordering. This is not much of a solution though, because as the table grows the 10% unallocated space will fill up and the performance will be back where we started. To explain the benchmarks shortly: - the performance difference between ints and sequential GUIDs is because GUIDs are larger - the performance difference between sequental and random GUIDs comes from appending records to the table vs inserts at random positions in the table - FILLFACTOR helps temporarily with random inserts by making space available before the inserts happen