Description:
Your current documentation states:
Each table has an .frm file that contains the table definition. The .frm file size limit is fixed at 64KB. If a table definition reaches this size, no more columns can be added. The expression that checks information to be stored in the .frm file against the limit looks like this:
if (info_length+(ulong) create_fields.elements*FCOMP+288+
n_length+int_length+com_length > 65535L || int_count > 255)
Though, four years ago a bug was created where this limit was already surpassed:
http://bugs.mysql.com/bug.php?id=4117
I am also surpassing the 64k limit, and landing right around the 81k mark. It seems that 81k is the new limit. How can this number be calculated now, since the documentation is not currently up to date?
How is the "Too many columns" error different from the "Row size too large. The maximum row size for the used table type..."? They seem to both be based on the frm size if I am understanding it correctly.
It also seems that two tables with different data types result in the same size frm file (see below)
How to repeat:
See http://bugs.mysql.com/bug.php?id=4117 for prior recreation for the "Too many columns" error.
A much smaller table, with different data types, creates the frm file.
CREATE TABLE IntTest (
JobID INTEGER,
col1 BIGINT
) engine = MyISAM
CREATE TABLE CharTest (
JobID INTEGER,
col1 CHAR(1)
) engine = MyISAM
Both these statements produce an 8k frm file. It seems that BIT(1), TINYINT, MEDIUMINT, INT, BIGINT, CHAR(1), and CHAR(8), all behave identically when creating an frm file. However, once VARCHAR gets into the mix then the frm filesizes are actually altered based on the data types. I'm looking to design a solution with these parameters in mind, and am looking for more details.