Is it a bad idea to use GUIDs as primary keys in MS SQL?

前端 未结 7 1365
时光说笑
时光说笑 2020-12-23 08:10

We have a system that uses UniqueIdentifier as the primary key of each of the tables. It has been brought to our attention that this is a bad idea. I have seen similar post

相关标签:
7条回答
  • 2020-12-23 08:23

    Personally, I'd use an int or bigint for the PK, but just put in another "Guid" column for those situations where you need an unguessable "key" for that record, and generate the Guid when you insert the row.

    0 讨论(0)
  • 2020-12-23 08:24

    There are pros and cons:

    This article covers everything.

    GUID Pros

    • Unique across every table, every database, every server
    • Allows easy merging of records from different databases
    • Allows easy distribution of databases across multiple servers
    • You can generate IDs anywhere, instead of having to roundtrip to the database
    • Most replication scenarios require GUID columns anyway

    GUID Cons

    • It is a whopping 4 times larger than the traditional 4-byte index value; this can have serious performance and storage implications if you're not careful
    • Cumbersome to debug (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
    • The generated GUIDs should be partially sequential for best performance (eg, newsequentialid() on SQL 2005) and to enable use of clustered indexes
    0 讨论(0)
  • 2020-12-23 08:31

    It will be bad if you will need to do joins over large sets (let's say 100,000ths). Been there, suffered that.

    Later Edit : I also encountered an even worse screw-up (can't call it "approach") : storing GUIDs in char(36) columns!!

    0 讨论(0)
  • 2020-12-23 08:35

    A GUID is a powerful datatype for identifying a row, since it is almost guarenteed to be unique, this allows a lot of flexibiliy for example you can generate the Guid in the application tier which can greatly simplify saving your relationships.

    As was said the big downside is the page splits which will occur if your PK is a clustered index; however, you can solve this by two ways. You could use the NewSequentialId() or you can set the PK to be non-clustered. I'd recommend you build your database based on your data requirements, and if you need a GUID use it, and then optimize around it. And validate its performance in your environment.

    0 讨论(0)
  • 2020-12-23 08:41

    I wrote a post about this last week with some code to show you what happens: Some Simple Code To Show The Difference Between Newid And Newsequentialid

    Basically if you use newid() instead of Newsequentialid() you get horrible page splits if your PK is a clustered index (which it will be by default)

    0 讨论(0)
  • 2020-12-23 08:43

    Jimmy Nilsson wrote a fantastic article about GUIDs vs. INTs and combined GUIDS. Conclusions...don't fear the GUID...well composite guids anyway.

    0 讨论(0)
提交回复
热议问题