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