Comments on: Learning about MySQL Table Fragmentation

By: peter

peter — Wed, 19 Nov 2008 15:41:34 +0000

Steven,

It really depends. In some cases when there is prevailing access method which is different from physical row layout it can make a huge difference. In other cases one may not know prevailing access or may not have time to run alter table order by regularly. Running ALTER TABLE … ORDER BY … is often much slower than OPTIMIZE TABLE.

By: Steven Roussey

Steven Roussey — Wed, 19 Nov 2008 06:04:21 +0000

Forget optimize table — better to use alter table order by xxx and force an arrangement by columns that you most often query against.

By: peter

peter — Tue, 13 May 2008 05:01:36 +0000

Peter,

Good catch though it does not have anything to do with table fragmentation. Simply if you’re querying number of rows in table for Innodb it performs estimation - this estimation requires several random dives in the clustered index, which causes IO for large table sizes.

By: Peter Laursen

Peter Laursen — Sun, 11 May 2008 08:40:08 +0000

I posted this to MySQL:
http://bugs.mysql.com/bug.php?id=36588

Originally we had this discussion in our Forums:
http://www.webyog.com/forums//index.php?showtopic=3925

Is this related, you think. Or am I overlooking something basic?

The culprit is that also SHOW TABLE STATUS can be very slow. Same for queries to Information_Schema fetching the same information. But it seems not always so - I have tried on my laptop and here it is not the case. Framentation makes the difference?

By: peter

peter — Wed, 07 May 2008 06:33:29 +0000

Jay,

Your method will require temporary table creation in MySQL which can be very large so it is better to use different query patterns as highlighted.

By: Jay Paroline

Jay Paroline — Wed, 07 May 2008 02:47:33 +0000

I have been using a similar method to ‘warm up the cache’ so to speak: SELECT 1 FROM (SELECT * FROM tablename) x LIMIT 1;
Is there any benefit from doing it your way over this way or are they pretty much the same thing?

By: Stewart Smith

Stewart Smith — Tue, 06 May 2008 03:41:27 +0000

You may want to check out filefrag, this will tell you (rather quickly) how many fragments your file has. This works on just about any file system (on linux).

If running XFS, xfs_bmap gives you much more detailed output. xfs_fsr will also (online) defragment the file. You can also use xfs_io to reserve space (resvspc) for files if you want to do this from the start.

By: peter

peter — Mon, 05 May 2008 20:24:47 +0000

Dathan,

Thanks - Indeed optimize/copy may not succeed defragmenting but this is as much as we can succeed trying to defragment something from application level.
Even if you do not have enough contiguos blocks in single piece the new file often would still have smaller number of fragments than old one.

By: Dathan Vance Pattishall

Dathan Vance Pattishall — Mon, 05 May 2008 19:26:48 +0000

just a note about “Optimize table” fixing file fragmentation and table space fragmentation: For ext-3 this is only true if there is enough contiguous blocks left on the disk for the new file created by optimize table-while the table space fragmentation is still solved with Optimize table.

http://mysqldba.blogspot.com/2008/01/filefrag-dbas-best-friend.html

By: peter

peter — Sun, 04 May 2008 04:47:04 +0000

Kevin,

I think non working read-ahead is result not the cause - if you have requests coming in a way read-ahead is not triggered it does not work