Multi-Column PK or Auto-Increment PK?
It depends.

One must weigh the alternatives.  Here is a partial list:


Rows are INSERTed in an ordered list (the BTree that contains the data, and is ordered by the PK) according to the PK.  For a huge table and random PK (eg UUID), this means jumping around a lot, which leads to poor caching.
New rows with an AUTO_INCREMENT PK are inserted at the "end" of the table, thereby avoiding the above point.
Every secondary key has a copy of the PK.  So, if the PK is bulky, you are taking more space for the secondary keys.
Ditto for other tables that need to JOIN to this table (with or without FOREIGN KEYs).
A PK is necessarily UNIQUE.  Hence, DATETIME and TIMESTAMP make risky fields to put into a PK.  (What if two things happened in the same second?)
Will you be fetching records based on the column(s) of a multi-column key that could be the PK?  If so, you get to them faster because you don't have to go through a secondary key faster.
Consecutive records (according to all columns of the PK) are "clustered" next to each other.  This means that fetching multiple rows will need fewer blocks from disk.
Etc, etc.