MySQL Row Size Calculator
MySQL checks a new table against two different row size limits, and ERROR 1118 (Row size too large) can come from either. The server rejects any row whose declared columns add up to more than 65535 bytes, where VARCHAR(n) counts n times the maximum bytes per character plus a 1 or 2 byte length, and TEXT, BLOB and JSON count only 9 to 12 bytes. InnoDB then checks that its worst-case record fits in half a 16 KB page: below 8126 bytes for DYNAMIC and COMPACT, 8123 for REDUNDANT. Here fixed-length columns count in full, while long variable-length columns count as 40 bytes (DYNAMIC) or a 768-byte prefix plus a 20-byte pointer (COMPACT and REDUNDANT). Paste one or more CREATE TABLE statements and the calculator applies both rules column by column, using each column's character set, the record header, the NULL bitmap and the hidden DB_TRX_ID, DB_ROLL_PTR and DB_ROW_ID fields. It also predicts ERROR 1074 for over-long VARCHAR and CHAR columns. Its results matched MySQL 8.4 on thousands of generated tables, including tables one byte below and one byte above each limit. Everything runs in your browser.
Assumes InnoDB with the default 16 KB innodb_page_size. ROW_FORMAT=COMPRESSED is estimated with the DYNAMIC rules.
Do more than mysql row size calculator — meet Chat2DB
Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.
How to use
- Paste one or more CREATE TABLE statements, including ROW_FORMAT and CHARSET options if you use them.
- Pick the server default character set and whether strict SQL mode and innodb_strict_mode are on, then click Calculate.
- Read the per-column bytes for both limits, the totals, the predicted error or OK, and the suggested fixes.
Frequently asked questions
Why do I get 'Row size too large (> 8126)' when my columns are far below 65535 bytes?
That message comes from InnoDB, not the MySQL server. A record must fit in half of a 16 KB page, so the worst-case record has to stay below 8126 bytes. Fixed-length columns such as CHAR in a single-byte character set, BINARY, DECIMAL and the integer and date types always stay in the row and count in full. In the default DYNAMIC format, VARCHAR, TEXT and BLOB values longer than 40 bytes can be moved off-page, so each counts as at most 41 bytes. In COMPACT and REDUNDANT tables they keep a 768-byte prefix in the row. Wide CHAR columns and COMPACT tables are the usual causes.
What does 'The maximum row size for the used table type, not counting BLOBs, is 65535' mean?
The MySQL server adds up the declared size of every column: VARCHAR(n) is n times the maximum bytes per character (4 for utf8mb4) plus 1 or 2 length bytes, CHAR(n) is n times the bytes per character, plus the NULL bitmap. TEXT, BLOB, JSON and geometry columns add only 9 to 12 bytes because their data is stored elsewhere. If the sum is over 65535 the CREATE TABLE fails, for example with three VARCHAR(6000) utf8mb4 columns. Changing the longest VARCHARs to TEXT fixes it.
Does turning off innodb_strict_mode fix error 1118?
It only turns the CREATE TABLE error into Warning 139 for the 8126-byte InnoDB check. The table is created, but any INSERT or UPDATE whose row really exceeds the limit then fails with ERROR 1118. With wide fixed-length CHAR columns that is every insert. It has no effect on the 65535-byte server limit. The safe fix is to change the schema. Chat2DB can show the table DDL and help you write the ALTER TABLE with its AI assistant: download it at chat2db.ai/download or open app.chat2db.ai in your browser.
