• A low cardinality NCI will also cause such splits.

    And that finally brings me to the point that I've been trying to make.

    As you said, you shouldn't just do the "best practice" thing. You need to actually think about things especially when it comes to large tables or, as Michael just pointed out, when you have nearly page-full wide rows to contend with. Just throwing a clustered index in the direction of performance of SELECTs is not enough. Just throwing a FILL FACTOR on a table/index so that INSERTs might run more quickly is not enough. Even if the creation of a perfect clustered index that will support all of your SELECT queries was possible (and, it's not unless you have just one form of criteria that always uses the same leading column), you have to consider more than just the performance of SELECTs.

    In some cases, "best practices" actually are (although I'll agree that many are not).

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)