Can't create NDB table in MySQL v8.0.28-CodePudding

I'm creating a table using the following statement:

   CREATE TABLE interfaces (
type VARCHAR(128),
name VARCHAR(1024), 
description VARCHAR(4096), 
ikey VARCHAR(1024), 
filename VARCHAR(4096), 
syntax VARCHAR(4096), 
hostname VARCHAR(256));

I get the error:

ERROR 1005 (HY000): Can't create table 'interfaces' (use SHOW WARNINGS for more info).

When I type SHOW WARNINGS; I'm presented with:

 --------- ------ -------------------------------------------------------------------- 
| Level   | Code | Message                                                            |
 --------- ------ -------------------------------------------------------------------- 
| Warning | 1296 | Got error 738 'Record too big' from NDB                            |
| Error   | 1005 | Can't create table 'interfaces' (use SHOW WARNINGS for more info). |
 --------- ------ -------------------------------------------------------------------- 
2 rows in set (0.00 sec)

From what I've read on the white papers for MySQL v8.0 here, is that:

Row size. In NDB 8.0, the maximum permitted size of any one row is 30000 bytes (increased from 14000 bytes in previous releases).

Don't I just simply add up the byte count in parenthesis of each column to see what my row size? ( 128 1024 4096 1024 4096 4096 256 = 14720 ) Am I missing overhead? And if so, is there REALLY an additional 15280 of overhead?

CodePudding user response：

The trouble is this: utf8mb4 Unicode characters use four bytes per character. If your columns used a one-byte character set (latin1 or ascii) your assumption would be correct.

CodePudding user response：

What is your default character set? It's utf8mb4 by default in MySQL 8.0, which means you count 4 bytes per character.

Therefore your row size is 14,720 characters * 4 bytes/character = 58,880 bytes.

utf8 is a variable-length encoding, so it's likely not every character will be a 4-byte character, but MySQL must assume that any or all characters in these strings might be 4-byte characters. Therefore it has to accommodate the maximum possible bytes per character when calculating the row size.