I shamelessly took title and content from this question and adapted it to my similar yet different problem:
This is the table I have:
CREATE TABLE `test` ( `field1` MEDIUMINT(8) UNSIGNED NOT NULL, `field2` INT(10) UNSIGNED NOT NULL, `field3` SMALLINT(5) UNSIGNED NOT NULL, `field4` SMALLINT(5) UNSIGNED NOT NULL, `field5` FLOAT UNSIGNED NOT NULL DEFAULT '0', PRIMARY KEY (`field1`, `field2`), INDEX `field2` (`field2`, `field1`) ) COLLATE='latin1_swedish_ci' ENGINE=ndbcluster ROW_FORMAT=DEFAULT
I expect the row length to be 15 bytes:
- 3 bytes for field1 mediumint(8)
- 4 bytes for field2 int(10)
- 2 bytes for field3 smallint(5)
- 2 bytes for field4 smallint(5)
- 4 bytes for field5 float
show table status; returns
Name: test Engine: ndbcluster Row_format: Fixed Rows: 143120123 Avg_row_length: 44 <-------------- (I assume this is in bytes?) Data_length: 7659913216
As you can see, I have quite a few rows, so row length really does matter.
Why does it take so much space?
And why is
Data_length so much bigger than expected?
Data_length - (Rows * Avg_row_length) = 7659913216 - 6297285412 = 1362627804 = 1.26 GB
And what are those digits in brackets after the type names for? (e.g.
I guess it's the char length of the field's string representations and I have the strange feeling that MySQL's ndbcluster engine stores them exactly like that!
Which seems amazingly stupid to me...