I just upgraded from MySQL 5.6 to 5.7, and had the bad surprise to discover that a WordPress plugin table contains a ridiculous 438 fields, and exceeds the row size limit of 8126 bytes.
Here is the warning I got when running
Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
This was just a warning though, and the table is still there. I can't create a new table with the same structure, but interestingly enough, I can keep the old table and use it (at least,
SELECT from it).
- changing to
ROW_FORMAT=DYNAMICis not enough, as the table is full of inline UTF-8
VARCHARfields that alone exceed the max size
- modifying the structure of the table is out of the question, as it's part of a third-party software, and that would be like opening a can of worms
I've reported the error to the plugin developers and hope they'll fix the table soon, but in the meantime, I'm stuck with this outlaw table.
So the questions are:
- How can MySQL work with a table that does not respect the InnoDB storage rules, when it does not allow to create such a table?
- Is there any risk to keep the table in its current state?
- Are there limitations on the type of queries I can run on this table?
- If I replicate this server to another MySQL 5.7 server, will the replication fail because of this table?
I upgraded from MySQL 5.6. I did try
COMPRESSED formats, but no luck. I calculated the size of the integer + varchar fields, they're totaling 17,059 bytes, so I have no chance to succeed this way.
The plugin is called Photo Gallery and the faulty table is