Robert,

I have some (hopefully viewed as constructive) criticisms:

The observed behaviour only applies to clustered tables - heap table inserts never cause page splits. Heap inserts are not counted by the "Access Methods:Page Splits/sec" counter, though they do naturally affect "Access Methods:Pages Allocated/sec".

Minimally-logged operations (even on a clustered table) do not cause "page splits" and so again only affect the 'pages allocated' counter. Taking the example of inserting into a SQL Server 2008 table clustered on a monotonically-increasing key, we observe zero page splits (but very many allocations) if the table is empty to begin with, and trace flag 610 is specified. I chose this example because it is minimally logged even under the FULL recovery model - the same behaviour applies to all other minimally-logged operations.

Adding a new page at the 'end' of the clustered index is indeed a page split: the new row is too large to fit on the last page, so it must split. Not moving any rows from the 'split' page is an optimization for this special case. Nevertheless, it explains why this operation counts as a page split.

The question explanation would have benefited from a reference - even if not officially documented. My recollection is that one of Kalen's internals books contains a reference to new page allocations in a clustered index being counted as a page split, though it does not (from memory) explain why.

The explanation given for the fourth answer option could have been worded more clearly, and again would have benefited from a reference to the internals book that explores that behaviour. QotD is useful to many people as a learning tool - so it makes sense to point them in the right direction if you can.

Paul