Sample Header Ad - 728x90

Why is there a big gap in the actual Table space? (calculated vs information_schema vs file size)

0 votes
1 answer
503 views
I have a InnoDB table with the following columns: BIGINT -> 8 bytes BIGINT -> 8 bytes ENUM(0,1) -> 1 byte MEDIUMINT -> 3 bytes INT -> 4 bytes = 24 bytes per row It contains 10454004 rows (based on COUNT(*)), so I calculate the Data size as **250MB**. This table's PRIMARY key is BIGINT, BIGINT, ENUM. And has an INDEX on the INT. Based on information_schema, DATA_LENGTH = **530.8MiB** INDEX_LENGTH = 272.0MiB DATA_FREE = 6.0MiB = 808.8MiB = **848 MB** Also, AVG_ROW_LENGTH = 87 instead of 24 And then I look at the actual .ibd file size, which is reported as: 1451229184 bytes = **1451.23 MB** I understand there is fragmentation and sparse files in question (the records on this table are regularly expired, but never had a bigger retention time than currently is). But I'm not understanding why do I see 3 different sizes, with such big gap each. Goes from 250MB of real calculable data, to 530MiB of Data. And DATA_FREE is only 6MiB. And 848 MB reported by information_schema (which per my understanding includes "free space" as well), much lower than the actual .ibd file. **From Comment** CREATE TABLE mytable ( uid bigint(18) unsigned NOT NULL, tid bigint(18) unsigned NOT NULL, fst enum('0','1') COLLATE utf8mb4_unicode_ci NOT NULL, sn mediumint(8) unsigned NOT NULL DEFAULT 1, ls int(10) unsigned NOT NULL, PRIMARY KEY (uid,tid,fst) USING BTREE, KEY ls (ls) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci **What am I missing or not considering?**
Asked by Nuno (829 rep)
Mar 11, 2022, 12:01 AM
Last activity: Sep 9, 2024, 02:01 PM