Estimating Records capacity
TIMESTAMP is 4, not 7.  So, you are starting with 18 bytes.

Since it is probably ENGINE=InnoDB, multiply that by 2 or 3.  Sorry, I can't be more precise than that.  So, perhaps 60 bytes/record.

If it is MyISAM, add 1 for overhead.  So, 19 bytes/record.  Add 1 more for up to 8 NULLable columns (apparently 1, the timestamp).  This takes a byte of 8 bits.  So, 20 bytes/record.  If you can make all columns NOT NULL, this byte can go away.

What is the average length of xxx?  If it is less than 6-1, use VARCHAR(6) instead of CHAR(6).  A short VARCHAR takes 1 byte for length plus the actual number of bytes needed for the string.

Consider normalizing xxx to save more space.

Are all the string columns ascii or latin1?  If not, then the above numbers may be wrong.  utf8 may take 3 bytes per character.  utf8mb4, 4 bytes.

If there are not many different values for the CHARs, consider a 1-byte ENUM.

What about indexes?  They take space.

InnoDB without PRIMARY KEY -- a 6-byte hidden PK.  So, it is almost always advisable to have an explicit PK.  If some column (or combo of columns) is always distinct, use it.

Any secondary index, plus MyISAM's PK -- another BTree, with another calculation.  Treat each index (but not  InnoDB's PK) like another table, but add 40% overhead due to BTree.