As a general rule, you should not use an autoincrement column for a PK if a natural PK exists. There can be exceptions. For example, if the table in question will then be referenced via foreign key by some other table, it might make sense to have the autonumber column for compactness and efficiency of the foreign key.
Even if that is true, though, there's no reason you couldn't create a UNIQUE index on the 3 columns, and there are many reasons to do so. With MySQL, there's not too much difference between a PRIMARY key and a UNIQUE index (not true in other DBs; in SQL Serve, the PRIMARY key actually influences strongly how the table is stored on disk).
But caution: With MySQL, composite keys have some nasty limitations.
If you were to then do the following queries, MySQL *would*use the primary key:
CREATE TABLE foo (
PRIMARY KEY (fieldA, fieldB, fieldC)
But if you did any of the following, MySQL *CAN NOT* use the primary key to speed queries:
SELECT ... WHERE fieldA='x' AND fieldB = '2013-1-1' AND fieldC=7
SELECT ... WHERE fieldA='x' AND fieldB = '2013-1-1'
SELECT ... WHERE fieldA='x'
And if you did this query, MySQL would only use the PK for fieldA, *not* for fieldC:
SELECT ... WHERE fieldB = '2013-1-1' AND fieldC=7
SELECT ... WHERE fieldC=7
All this is because MySQL can *ONLY* use the fields in the composite key in left-to-right order, without skiipping any.
SELECT ... WHERE fieldA='x' AND fieldC=7