Estimating Records capacity A small MySQL 5.5.58 Ubuntu test database was setup with a constraint of 5MB.  It consists of a single table:
CREATE TABLE IF NOT EXISTS scanpoint (
         xxx      CHAR(6)              NOT NULL DEFAULT '',
         YYYYYYY  CHAR(2)              NOT NULL DEFAULT '',
         ZZZZZZ   SMALLINT UNSIGNED    NOT NULL DEFAULT 0,
         AAAAAA   CHAR(3)              NOT NULL DEFAULT '',
         BBBBBB   TINYINT UNSIGNED     NOT NULL DEFAULT 0,
         CCCCCC   TIMESTAMP
       );

I would like to estimate the records capacity of a 5MB database:
CHAR:       11 bytes =6+2+3
SMALLINT:    2 bytes
TINYINT:     1 byte
TIMESTMAP:  7 bytes?

TOTAL        21 bytes per record  =&gt; 2.38E5 records = 5MB /21 bytes/rec
QUESTION: Is there any consideration / logic that would adjust the calculation to sharpen the estimate?
UPDATE
xxx records will always have 6 characters.  In similar fashion,  the same other character arrays follow suit.  YYYYYY will always have 2 charaters and AAAAAA will always have 3 characters
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.