I see a whole lot of typical answers on this thread about Random GUIDs and things like NEWSEQUENTIALID() saving the day. Yes, I do agree GUIDs in any form are quite large but that's really the only problem they have. I'll tell you that Random GUIDs are NOT the fragmentation problem that they they've supposedly been "proven" to be. In probably the most heterodoxical presentation about SQL Server that you'll ever see, I prove that Random GUID fragmentation is actually a myth perpetuated by insufficient testing and misinformation. It turns out they're not the problem... WE ARE THE PROBLEM!
To summarize on how to prevent GUID fragmentation quite literally for millions of inserts...
Because of the even distribution, when you reach about 1% fragmentation, you're on the verge of massive fragmentation happening in the table on virtually all pages all at once. You must take action when you go over 1% logical fragmentation.
The action that you need to take is to create free-space above the Fill Factor. That means that you MUST NOT USE REORGANIZE because it's not capable of creating additional pages to spread out the index to make the free-space above the Fill Factor. In fact, REORGANIZE COMPACTS pages UP to the Fill Factor. In other words, it does its best to remove as much free space as possible at the worst possible time. Instead, you MUST use a REBUILD instead.
It also turns out that because of the compaction, REORGANIZE actually causes and perpetuates fragmentation. It turns out that it's actually better to NOT do any index maintenance rather than to do it wrong and the compaction of the index that REORGANIZE does is doing it totally wrong because it cannot create the free space above the Fill Factor to stop the fragmentation. If you're 24/7 or using the Standard Edition where you can't do an ONLINE rebuild, then wait for a maintenance period when you can.
Additionally, REORGANIZE is advertised as being much less resource intensive than REBUILD. That's actually not true especially when you've lowered the Fill Factor to prevent fragmentation even on non-GUID indexes.
I agree that because of what we've been taught over the years, this all seems impossible. Here's the final slide of a presentation I made that shows the one year history of GUID Clustered Indexes (see the legend) using presorted GUIDs as an ever-increasing baseline with no fragmentation, Random GUIDs with no index maintenance, and Random GUIDs with 3 different Fill Factors where the 1% "Low Threshold" Rebuilds were used at an insert rate of 100 THOUSAND rows per day.
Here's one of the slides that show how bad REORGANIZE is for the log file. The Red Line is the supposed "Best Practice" line and the little tiny GREEN LINE at the very bottom of the chart is the 1% "Low Threshold" Rebuild Line.
If you care to see the presentation, please see the following video where I destroy the myths of Random GUID fragmentation and lay waste to the supposed "Best Practice" Index Maintenance that 98% of the world has made the mistake of using for the past 22 years. Then, also understand that the lessons learned about index maintenance apply to other types of indexes.
Here's the video link. As warning for those wearing headsets, they inserted some rather suddenly occurring and loud ads at the 15:00, 30:15, and 45:25 timestamps to "pay the bills" to keep GROUPBY.org going.
Here's the link.
Black Arts Index Maintenance 1.2 - Guids vs. Fragmentation