MySQL raises ER_TOO_BIG_ROWSIZE when the combined fixed-length columns in a table exceed the storage engine’s maximum row size, usually 8126 bytes for InnoDB.
MySQL Error 1118: ER_TOO_BIG_ROWSIZE occurs when the sum of fixed-length columns exceeds the storage engine’s row size limit (≈8126 B for InnoDB). Reduce column widths, convert large VARCHARs to TEXT, or switch to DYNAMIC/COMPRESSED row formats to resolve the issue.
Row size too large. The maximum row size for the used
The message “Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126” means MySQL cannot create or alter a table because its fixed-length columns require more space than InnoDB pages can hold.
InnoDB stores each row inside a 16 KB page. After overhead, only about 8126 bytes remain for fixed-length data.
When a CREATE TABLE or ALTER TABLE statement pushes the total past that threshold, the server stops with SQLSTATE 42000 and error 1118.
.
Oversized fixed-length columns trigger the problem most often. Many CHAR, INT, DECIMAL, and VARCHAR(n) columns with high n values quickly consume space. Even if a VARCHAR is seldom full, its maximum length is used for the limit calculation when packed into the page.
Tables created with the COMPACT row format are more susceptible because long VARCHARs are stored inline. Mixing large ENUMs or complex multi-column primary keys can also inflate row size beyond the 8126-byte ceiling.
Lower the total fixed length by converting bulky VARCHAR/CHAR columns to variable-length TEXT or BLOB types. MySQL counts TEXT/BLOB as only 20 bytes in the row because the actual data moves off-page.
Change the row format to DYNAMIC or COMPRESSED so variable-length columns are stored off-page. This often resolves the error with no schema redesign.
A migration script that adds dozens of VARCHAR(255) columns fails. Converting rarely used columns to TEXT avoids the limit without harming application logic.
A wide analytics table with many DECIMAL(38,18) measures cannot be created. Switching to DOUBLE, partitioning the table, or splitting the schema fixes the row size while retaining precision where required.
Model tables narrowly. Move large descriptive fields to separate tables or use JSON/TEXT columns. Always prefer VARCHAR to CHAR unless the column truly has fixed width.
Set innodb_default_row_format=DYNAMIC in my.cnf so new tables automatically benefit from off-page storage. Monitor schema diff tools and CI pipelines for CREATE or ALTER statements that breach safe limits. Galaxy’s schema-aware linter surfaces such issues before code reaches production.
Error 1074 (ER_TOO_BIG_STRING) appears when a single column definition exceeds 65 535 bytes. The remedy is similar: downsize or split the column.
Error 1114 (ER_TOO_BIG_ROWSIZE_FOR_BLOB) occurs when BLOB/TEXT in a single row exceed 65 535 bytes. Compressing or normalizing the data eliminates the failure.
Every VARCHAR counts its maximum length toward the 8126-byte row limit, so dozens of VARCHAR(255) fields quickly exhaust space.
High-precision DECIMAL and ENUM columns are stored as fixed length, inflating the row size even when values are small.
Tables created with COMPACT keep variable-length data inline, using more page space than DYNAMIC or COMPRESSED formats.
Including many columns in a PRIMARY KEY duplicates that data in every secondary index, effectively multiplying row width.
.
TEXT columns cannot be fully indexed; you must supply a prefix length. Evaluate query plans before converting key columns.
InnoDB’s per-page limit remains roughly 8126 bytes in MySQL 5.6 through 8.0. Smaller page sizes reduce the limit further.
Yes. Setting this global variable ensures new tables use DYNAMIC by default, preventing inline overflow.
Galaxy’s SQL editor highlights schema changes that breach row-size thresholds and suggests safe conversions before running DDL.
.avif)
.avif){kind=logo}
