Im creating the following table in mysql 5.7.44: CREATE TABLE `test_max_row_size`

(
`log_counter` int NOT NULL AUTO_INCREMENT,
`insert_date` datetime NOT NULL,
`log_description` text NOT NULL,
`ip` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
`did` varchar(50) DEFAULT NULL,
`useragent` text,
`userip` varchar(255) DEFAULT NULL,
`device` varchar(255) DEFAULT NULL,
`device_type` varchar(255) DEFAULT NULL,
`os` varchar(255) DEFAULT NULL,
`countrycode` varchar(255) DEFAULT NULL,
`city` varchar(255) DEFAULT NULL,
`attribution` varchar(2048) DEFAULT NULL,
`lookback` varchar(255) DEFAULT NULL,
`date_time` varchar(255) DEFAULT NULL,
`guid` varchar(255) DEFAULT NULL,
`package` varchar(255) DEFAULT NULL,
PRIMARY KEY (`log_counter`,`insert_date`),
KEY `log_value` (`ip`),
KEY `NewIndex2` (`insert_date`),
KEY `sdsd` (`did`,`package`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
but on mysql 8.0.35 the same table results with this error:
2024-08-08T11:06:00.424575Z 10 [ERROR] [MY-011825] [InnoDB] Cannot add field `date_time` in table `test`.`test_max_row_size` because after adding it, the row size is 8707 which is greater than maximum allowed size (8126) for a record on index leaf page.

Why?

The reason you didn't encounter the row size error in MySQL 5.7, but did in MySQL 8.0, stems from differences in how these two versions handle row storage and enforce limits. Here’s why: ### 1. Row Storage and Format Differences: - MySQL 5.7: - By default, MySQL 5.7 uses the COMPACT row format. In this format, MySQL stores a portion of long VARCHAR or TEXT column data within the row itself, while the rest is stored in overflow pages if necessary. This approach sometimes allowed rows to be larger than the strict 8126-byte limit, but it was less consistent and predictable. - MySQL 8.0: - MySQL 8.0 introduced stricter enforcement of row size limits and made improvements to the InnoDB storage engine, including changes to how row formats are handled. The new default behavior is more stringent about keeping the total size of the indexed columns within the 8126-byte limit, which can result in errors during table creation if this limit is exceeded. ### 2. Stricter Validation in MySQL 8.0: - MySQL 8.0 includes more rigorous validation checks during the CREATE TABLE process, ensuring that rows do not exceed the maximum allowable size. This stricter enforcement is likely the reason why the table creation fails in MySQL 8.0, while it succeeded in MySQL 5.7. ### 3. Differences in Default Row Format: - While MySQL 5.7 might default to COMPACT row format, MySQL 8.0 defaults to DYNAMIC for new tables created in InnoDB. However, the underlying issue in MySQL 8.0 is more about its improved error checking and enforcement of row size constraints, regardless of the row format. ### 4. Different Handling of Indexes: - The ROW_FORMAT=COMPACT in MySQL 5.7 might have allowed you to create an index on several large VARCHAR columns without immediate errors, but the actual row size could exceed what’s allowed when data is inserted or updated, leading to potential runtime issues. MySQL 8.0’s checks prevent this upfront by ensuring that the table structure won’t lead to row size issues. ### Conclusion: In MySQL 5.7, the table creation succeeded because the row size checks were less strict, and the default row format might have handled large rows differently. MySQL 8.0, however, has stricter checks and row size enforcement, leading to the error you encountered. The ROW_FORMAT=DYNAMIC can help in MySQL 8.0 by storing large VARCHAR and TEXT columns off-page, reducing the in-row size and avoiding the row size limit error.

Change attribution Varchar to 255