Maximum No. of Indexes

  • Sriram-288748

    SSCrazy

    Points: 2874

    Comments posted to this topic are about the item Maximum No. of Indexes

    Sriram

  • ChiragNS

    One Orange Chip

    Points: 26137

    In BOL under Creating Indexes (Database Engine) section its mentioned that there can be 249 non clustered indexes per table.

    But In BOL under Create table sections its mentiond 999 😉

    "Keep Trying"

  • Adi Cohn-120898

    SSC-Dedicated

    Points: 33944

    Chirag (3/20/2009)


    In BOL under Creating Indexes (Database Engine) section its mentioned that there can be 249 non clustered indexes per table.

    But In BOL under Create table sections its mentiond 999 😉

    In that case BOL has a bug:-D

    Adi

    --------------------------------------------------------------
    To know how to ask questions and increase the chances of getting asnwers:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

    For better answers on performance questions, click on the following...
    http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

  • Betim Drenica

    Old Hand

    Points: 381

    I am also confused because in BOL (Indexes Section) is mentioned 249

    {The maximum number of nonclustered indexes that can be created per table is 249.}

    . This is a really documentation bug I think. Even if, I'll expend some time to prove this in my srv.

  • Hugo Kornelis

    SSC Guru

    Points: 64685

    Chirag (3/20/2009)


    In BOL under Creating Indexes (Database Engine) section its mentioned that there can be 249 non clustered indexes per table.

    But In BOL under Create table sections its mentiond 999 😉

    As others have already said, this is a documentation bug in BOL. The maximum number of nonclustered indexes was 249 on SQL Server 2005 and before, but the maximum has been increased to 999 for SQL Server 2008. Apparently, MS has overlooked one page when applying this modification to BOL.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Andrew Watson-478275

    SSCarpal Tunnel

    Points: 4652

    Just as well one of the answers wasn't 250, or I would have gone for that (1C + 249NC). I hit the wrong page in BOL first, and it's only when the answer I was expecting wasn't in the choices that I dug a bit further.

    Couldn't the answer also be 1498 when we take the 249 XML indices and 249 spacial indices into account as well?

  • Sriram-288748

    SSCrazy

    Points: 2874

    Yes, the answer could have been that also, but for in the question we have (clustered + non clustered) explicitly mentioned.

    Sriram

  • Luke L

    SSC-Dedicated

    Points: 35529

    How very un-binary of them... I found 999 an odd number to have as a maximum.

    To help us help you read this[/url]

    For better help with performance problems please read this[/url]

  • Rudyx - the Doctor

    SSC-Forever

    Points: 43696

    Regardless of the discrepancy, 249 or 999, any design that requires anywhere near that theoretical maximum, is most probably a 'pile of dung' !

    RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

  • Steven Cameron

    SSCrazy

    Points: 2903

    When the question specifies the version of SQL Server, you should double check that the selected article in BOL is for that version. The Local Help search in BOL lists only the 2005 version of CREATE INDEX while the MSDN Online search section lists articles for both the 2005 and the 2008 versions.

  • Andrew Watson-478275

    SSCarpal Tunnel

    Points: 4652

    I do have the 2008 BOL on my desktop. CREATE INDEX is OK, but it's wrong in the "Implementing Indexes" section of "Designing and Implementing Structured Storage".

  • Mauve

    SSChampion

    Points: 11316

    Andrew Watson (3/20/2009)


    I do have the 2008 BOL on my desktop. CREATE INDEX is OK, but it's wrong in the "Implementing Indexes" section of "Designing and Implementing Structured Storage".

    Likewise. I have the January 2009 edition of the SQL Server 2008 BOL. In the section titled "Index Creation Tasks"

    (local URL: ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.en/s10de_1devconc/html/b182c8be-581e-4ec8-86d2-31557ee05b25.htm)

    it still states the SQL Server 2005 values.

    Interesting, the entire section has been eliminated/reworked in the February, 2009 edition -- which is only available online at: http://msdn.microsoft.com/en-us/library/ms180857.aspx

    Edit: It is still wrong there: http://msdn.microsoft.com/en-us/library/ms190197.aspx

    So depending upon what Microsoft material you reference, there are two different answers. However, the value 250 (1 clustered and 249 nonclustered) was NOT one of the answers. So if you responded 249 you are still wrong.


    [font="Arial Narrow"](PHB) I think we should build an SQL database. (Dilbert) What color do you want that database? (PHB) I think mauve has the most RAM.[/font]

  • john.arnott

    SSChampion

    Points: 11882

    Interesting QOD. It's good to know that SQL 2008 has raised a limit that some may have come up against. Also interesting that (as of this posting), the responses look about as close to a guess-fest as possible:

    249 -- 21%

    255 -- 28%

    1000 -- 24%

    1024 -- 27%

  • The Dixie Flatline

    SSC Guru

    Points: 53253

    Another link for 249. Fortunately I will never need anywhere near that number.

    http://msdn.microsoft.com/en-us/library/ms190197.aspx

    __________________________________________________

    Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
    Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills

  • BudaCli

    Hall of Fame

    Points: 3378

    Nice and simple

    What you don't know won't hurt you but what you know will make you plan to know better

Viewing 15 posts - 1 through 15 (of 17 total)

You must be logged in to reply to this topic. Login to reply