Mysql timestamp and AUTO_INCREMENT as primary key

Question

I am thinking about the best way to index my data. Is it a good idea to use the timestamp as my primary key? I am saving it anyway and I though about saving some columns. The timestamp should be an integer not a datetime column, because of performance. Moreover I don't want to be restricted on the amount of data in a short time (between two seconds). Therefore, I thought about an additionary AUTO_INCREMENT column. Now I have a unique key (timestamp and AI) and I can get the current inserted id easily by using the command "LAST_INSERT_ID". Is it possible to reset the AI counter every second / when there is a new timestamp? Or is it possible to detect if there is a dataset with the same timestamp and increase the AI value (I still want to be able to use LAST_INSERT_ID).

Please share some thoughts.

Answer 1

The timestamp should be an integer not a datetime column, because of performance.

I think you are of the belief that datetime is stored as a string. It is stored as numbers quite efficiently and with a wider range andmore accuracy than an integer.

Using an integer may decrease performance because the database may not be able to correctly index it for use as a timestamp. It will complicate queries because you will not be able to use the full suite of date and time functions without first converting the integer to a datetime.

Use the appropriate date/time type, index it, and let the database optimize it.

Moreover I don't want to be restricted on the amount of data in a short time (between two seconds). Therefore, I thought about an [additional] AUTO_INCREEMENT column.

This would seem to defeat the point of "saving some columns". Now your primary key is two integers. Worse, it's a compound key which requires all references to store both values increasing storage requirements and complicating joins.

All the extra work necessary to determine the next primary key could be done in an insert trigger , but now you'd added complexity and extra work to every insert.

Is it a good idea to use the timestamp as my primary key?

A primary key should be A) unique and B) immutable. A timestamp is not unique, and you might need to change it.

Your primary key is unlikely to be a performance or storage bottleneck. Unless you have a good reason, stick with a simple, auto-incrementing big integer. A big integer because 2 billion is smaller than you think.

MySQL encapsulates this in serial which is bigint unsigned not null auto_increment unique .

Answer 2

TIMESTAMP and DATETIME are risky as a PRIMARY KEY since the PK must be Unique.

Otherwise, it is fine to use them for the PK or an index. But here are some caveats:

• When using composite indexes (multi-column), put the things tested with = first; put the datetime last.
• Smaller is slightly better when picking a PK. TIMESTAMP and DATETIME take 5 bytes (when not including microseconds); INT is 4 bytes; BIGINT is 8.
• The time taken for comparing one PK value to another is insignificant. That includes character PKs. For example, country_code CHAR(2) CHARACTER SET ascii is only 2 bytes -- better than 'normalizing' it and replacing it with a 4-byte cc_id INT .
• So, no, don't bother using INT instead of TIMESTAMP.
• In my experience, 2/3 of tables have a "natural" PK and don't need an auto_increment PK.
• One of the worst places to use a auto_inc is on a many-to-many mapping table. It is likely to slow down most operations by a factor of 2.

You hinted at PRIMARY KEY(timestamp, ai) :

• You need to add INDEX(ai) to keep AUTO_INCREMENT happy.
• It provides locality of reference for temporarily 'near' rows. But so does ai , by itself.
• No, there is no practical way to reset the ai each second. (MyISAM has such, but do not use that engine.) Instead be sure to declare ai big enough to last 'forever' before overflowing.
• But I can't think of a use case where there isn't a better way.