Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Primary key mysql using auto increment id or a sha1 hash?

I can either have an auto increment id field as my primary key or a sha1 hash.

Which one should I choose?

Which would be better in terms of performance?

like image 576
cgwebprojects Avatar asked May 26 '12 05:05

cgwebprojects


People also ask

Does MySQL auto increment primary key?

The Auto Increment feature allows you to set the MySQL Auto Increment Primary Key field. This automatically generates a sequence of unique numbers whenever a new row of data is inserted into the table.

Can auto increment be a primary key?

Auto-increment allows a unique number to be generated automatically when a new record is inserted into a table. Often this is the primary key field that we would like to be created automatically every time a new record is inserted.

Does MySQL auto generate ID?

Auto increment syntaxThis causes the category Id to be automatically generated every time a new row is inserted into the table. It is not supplied when inserting data into the table, MySQL generates it.

How do you set a field as auto increment in MySQL?

In MySQL, the syntax to change the starting value for an AUTO_INCREMENT column using the ALTER TABLE statement is: ALTER TABLE table_name AUTO_INCREMENT = start_value; table_name.


1 Answers

There are a few application-driven cases where you'd want to use a globally unique ID (UUID/GUID):

  1. You expect to (or are) using a sharding strategy to scale writes. You don't want the shard nodes to duplicate keys.
  2. You want to be able to safely port data from one node to another preserving keys. This is critical if you want to keep foreign-key relationships in-tact.
  3. Your application is also used offline (in-home sales, in-home repairs, etc.) where the offline application periodically syncs with the "source of truth". You'd want those offline keys to be unique without having to make a remote call. Otherwise, it is up to you to come up with a strategy to reorganize keys and relationships on the way in. With an auto-increment strategy and depending on the RDBMS you are using, this is likely a non-trivial task.

If you don't have a use-case from above or something similar, you may use an auto-increment id if that makes you comfortable; however, you may still want to consider UUID/GUID

The Trade Off:

There are a lot of opinions held about the speed / size of UUID/GUID keys. At the end of the day, it is a trade-off and there are lots of ways to gain or lose speed with a database. Ideally, you want your indexes to be stored in RAM in order to be as fast as possible; however, that is a trade-off you have to weigh against other considerations.

Other Considerations regarding UUID/GUID:

  1. Many RDBMS can produce a UUID.
  2. You can also produce a UUID via your application (you aren't tied to the RDBMS to generate).
  3. Developers / Testers can easily port data from environment to environment and have the application work as expected. This is an often overlooked use-case; however, it is one of the stronger cases for using a UUID/GUID strategy.
  4. There are databases that are optimized for use offline (CouchDB) where UUID is what you get.
like image 145
Wil Moore III Avatar answered Oct 12 '22 23:10

Wil Moore III