Comments on: Changes to InnoDB autoextend coming in MySQL 5.6 http://www.xaprb.com/blog/2012/10/08/changes-to-innodb-autoextend-coming-in-mysql-5-6/ Stay curious! Thu, 02 May 2013 12:36:53 +0000 hourly 1 http://wordpress.org/?v=3.5.1 By: James Day http://www.xaprb.com/blog/2012/10/08/changes-to-innodb-autoextend-coming-in-mysql-5-6/#comment-20338 James Day Mon, 15 Oct 2012 20:32:59 +0000 http://www.xaprb.com/blog/?p=2893#comment-20338 It turns out that my original blog entry was wrong and this was never changed to apply to ibd files. I’ve corrected the blog post. Sorry about the confusion!

The initial size in 5.0.60 is 96k. The ibd minimum space rule is 64k + n*16k for each index including the PK and doesn’t seem to have been changed. Thanks for asking about the 96k part and prompting me to check on that.

James

]]> By: Xaprb http://www.xaprb.com/blog/2012/10/08/changes-to-innodb-autoextend-coming-in-mysql-5-6/#comment-20333 Xaprb Thu, 11 Oct 2012 15:12:03 +0000 http://www.xaprb.com/blog/?p=2893#comment-20333 Hmm – MySQL 5.5 creates a 96kb .ibd file too. I thought I remembered an empty table was 16kb at one point in time. Am I wrong, or has something changed since, say, MySQL 5.0?

]]> By: Xaprb http://www.xaprb.com/blog/2012/10/08/changes-to-innodb-autoextend-coming-in-mysql-5-6/#comment-20332 Xaprb Thu, 11 Oct 2012 15:09:07 +0000 http://www.xaprb.com/blog/?p=2893#comment-20332 I’ve started up the RC and created an empty InnoDB table. The size of the .ibd file is 96kb. Why? I was expecting 16kb or 64MB based on what you wrote.

]]> By: James Day http://www.xaprb.com/blog/2012/10/08/changes-to-innodb-autoextend-coming-in-mysql-5-6/#comment-20331 James Day Tue, 09 Oct 2012 03:14:11 +0000 http://www.xaprb.com/blog/?p=2893#comment-20331 Baron,

For some of the background on this see http://bugs.mysql.com/bug.php?id=31592 . It’s intended in part to help larger table scans, particularly on spinning disks, where the high disk i/o can cause significant production disruption.

As you can see, there was some consideration given to being cleverer about the extension size initially but it was ultimately implemented just as a simple change. We can revisit that if it turns out to have broad adverse effects.

If you try smallish benchmarks you may see a small performance drop, depending on how significant the extension is to the total amount of work being done in the benchmark. Perhaps 1-3%, depending on specific benchmark, though it’s possible to deliberately construct worse results than those by paying attention to thresholds to amplify the effect.

Most of the work is done in the background in 5.6 but there is still a brief time when a lock is taken. They are mostly a concern for those with lots of very fast queries and low tolerance for query run time variation. Full background pre-extending will eliminate this but it’s not in 5.6.

Those with really fast solid state storage might find it better to reduce the size, since they aren’t going to be affected much by fragmentation. Those with big tables on spinning disks might prefer bigger. Those with small tables might prefer smaller, like 1m, and can set that.

While we’ve changed the default to innodb_file_per_table being on in 5.6, people are also free to turn it off again if they like. That’s part of the ultimate solution for those suffering badly from small table issues.

You might also find it of interest to explore the potential of the feature mentioned at https://blogs.oracle.com/mysqlinnodb/entry/choose_the_location_of_your and how it does and doesn’t interact with this.

Have fun experimenting with this! :)

Views are my own, for an official Oracle view seek out a PR person.

James Day, MySQL Senior Principal Support Engineer, Oracle

]]>