Question

I took an existing MySQL database, and set up a copy on a new host.

The file size for some tables on the new host are 1-3% smaller than their counterpart files on the old host.

I am curious why that is.

My guess is, the old host’s files have grown over time, and within the b-tree structure for that file, there is more fragmentation. Whereas the new host, because it was creating the file from scratch (via a binary log), avoided such fragmentation.

Does it even make sense for there to be fragmentation within the b-tree structure itself? (Speaking within the database layer, and not with regards to the OS file system layer) I originally thought “no”, but then again, isn’t such fragmentation the basis for the DBA task of compressing your database files?

I’m wondering maybe if this is simply an artifact of the file system layer. i.e. the new host has a mostly empty disk drive, hence less fragmentation would result in the allocation of a new file. Then again, I didn’t think that fragmentation would show up in the reported file size (Linux OS).

Answer 1

There can certainly be fragmentation in MySQL data files or index files. This is common, even deliberate.

That is, the storage engine may deliberately leave some extra space here and there so when you change values, it can fit the rows in without having to reorder the whole data file. There are even server properties you can use to configure how much of this slop space to allocate.

I wouldn’t even blink at a file discrepancy of 1-3%.