Comments on: Reasons to use innodb_file_per_table http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table Blog by Shlomi Noach Thu, 11 Mar 2010 12:08:37 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: shlomi http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-6462 shlomi Thu, 12 Nov 2009 06:11:26 +0000 http://code.openark.org/blog/?p=614#comment-6462 Hi, They guy who absolutely hates innodb_file_per_table would be <a href="http://dammit.lt/2009/05/21/innodb-tablespace/" rel="nofollow">Domas Mituzas</a>. I disagree with part of his arguments. But he is an expert in the field, so this does not mean I belittle him. It's just that there's some contention between "what's utterly best for performance" and "what's best to live with". The two do not work well together. There's reasons for and against. I've presented the reasons "for". As I see it, the development is moving in the direction of innodb_file_pre_table: the innodb plugin has to use this option if you want to use Barracuda table format (which allows for compression, among other things). Anyway, I don't get paid to support innodb_file_per_table :) I'll use the single tablespace if I think it's superior. Regards Hi,

They guy who absolutely hates innodb_file_per_table would be Domas Mituzas.
I disagree with part of his arguments. But he is an expert in the field, so this does not mean I belittle him. It’s just that there’s some contention between “what’s utterly best for performance” and “what’s best to live with”. The two do not work well together.

There’s reasons for and against. I’ve presented the reasons “for”.
As I see it, the development is moving in the direction of innodb_file_pre_table: the innodb plugin has to use this option if you want to use Barracuda table format (which allows for compression, among other things).

Anyway, I don’t get paid to support innodb_file_per_table :) I’ll use the single tablespace if I think it’s superior.

Regards

]]> By: Mikev http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-6460 Mikev Thu, 12 Nov 2009 05:25:22 +0000 http://code.openark.org/blog/?p=614#comment-6460 I have found various blogs/sites on the net attacking the innodb_file_per_table setting due to extra threads and disk io usage that can occur. This guys post appears to be the most complete with small benchmark examples of fdatasync/sec numbers http://yoshinorimatsunobu.blogspot.com/2009/05/overwriting-is-much-faster-than_28.html I lost some of the other links there is this other guys blog that totally hates it and he seemed like his arguments were quite good. I read since I closed by browser down earlier today. Seems like if you value the odd amount of disk space over performance by all means enable innodb_file_per_table but if you value performance above easy management thing don't use this setting. Also I grabbed this out of the "High performance MYSQL" Book. 'Innodb_file_per_table causes each file to be fsynced separately, which means writes to multiple tables can't be combined into a single I/O operation. This may require InnoDB to perform a higher total number of fsync() operations.' I have found various blogs/sites on the net attacking the innodb_file_per_table setting due to extra threads and disk io usage that can occur.
This guys post appears to be the most complete with small benchmark examples of fdatasync/sec numbers

http://yoshinorimatsunobu.blogspot.com/2009/05/overwriting-is-much-faster-than_28.html

I lost some of the other links there is this other guys blog that totally hates it and he seemed like his arguments were quite good. I read since I closed by browser down earlier today.

Seems like if you value the odd amount of disk space over performance by all means enable innodb_file_per_table but if you value performance above easy management thing don’t use this setting.

Also I grabbed this out of the “High performance MYSQL” Book.

‘Innodb_file_per_table causes each file to be fsynced separately, which means writes to multiple tables can’t be combined into a single I/O operation. This may require InnoDB to perform a higher total number of fsync() operations.’

]]> By: shlomi http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-6458 shlomi Thu, 12 Nov 2009 04:20:20 +0000 http://code.openark.org/blog/?p=614#comment-6458 @Mikev, I'm not aware that there's a difference in write speed. Can you point out the references? Thanks @Mikev,

I’m not aware that there’s a difference in write speed. Can you point out the references?
Thanks

]]> By: Mikev http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-6449 Mikev Thu, 12 Nov 2009 01:51:52 +0000 http://code.openark.org/blog/?p=614#comment-6449 I been googling around and it appears to do get slower write speeds with innodb_file_per_table enabled. Personally I don't give a dam about gaining file space here and there I am far more concerned about total speed performance then possible space. I been googling around and it appears to do get slower write speeds with innodb_file_per_table enabled.
Personally I don’t give a dam about gaining file space here and there I am far more concerned about total speed performance then possible space.

]]> By: shlomi http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-3330 shlomi Tue, 18 Aug 2009 15:51:49 +0000 http://code.openark.org/blog/?p=614#comment-3330 Whatever you do - make a backup first! Whatever you do – make a backup first!

]]> By: Feuchttraum http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-3327 Feuchttraum Tue, 18 Aug 2009 15:00:20 +0000 http://code.openark.org/blog/?p=614#comment-3327 @schlomi, thank you for fast reply. I also think it should work, I just wanted to be sure first. It will save me some time, since doing mysqldump on 45 GB database can take quite long. @schlomi, thank you for fast reply. I also think it should work, I just wanted to be sure first. It will save me some time, since doing mysqldump on 45 GB database can take quite long.

]]> By: shlomi http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-3326 shlomi Tue, 18 Aug 2009 14:47:58 +0000 http://code.openark.org/blog/?p=614#comment-3326 @Feuchttraum I'm not sure about defragmenting files on windows. If you say that's feasable, then, yes, you can take the service down and work on the file during that time. @Feuchttraum

I’m not sure about defragmenting files on windows. If you say that’s feasable, then, yes, you can take the service down and work on the file during that time.

]]> By: Feuchttraum http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-3325 Feuchttraum Tue, 18 Aug 2009 14:42:39 +0000 http://code.openark.org/blog/?p=614#comment-3325 My ibdata1 is 45 GB. MySQL server runs on my Windows development machine and file ibdata1 is severely fragmented. Defrag programs cannot defragment it. Can I temporarily (while MySQL service is down) move ibdata1 file to another drive, defragment the first drive (actually a partition) and then move ibdata1 back? My ibdata1 is 45 GB. MySQL server runs on my Windows development machine and file ibdata1 is severely fragmented. Defrag programs cannot defragment it. Can I temporarily (while MySQL service is down) move ibdata1 file to another drive, defragment the first drive (actually a partition) and then move ibdata1 back?

]]> By: nos http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-2529 nos Fri, 03 Jul 2009 17:50:10 +0000 http://code.openark.org/blog/?p=614#comment-2529 innodb_per_table has one other drawback. You'll use more resources. Namely, mysqld will need to keep 1 open file per table. This can be a problem if you have _many_ tables. (Ofcourse, myisam tables always had that issue) innodb_per_table has one other drawback.
You’ll use more resources. Namely, mysqld will need to keep 1 open file per table. This can be a problem if you have _many_ tables. (Ofcourse, myisam tables always had that issue)

]]> By: Artículos destacados, Mayo de 2009 | cambrico.net http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table/comment-page-1#comment-2276 Artículos destacados, Mayo de 2009 | cambrico.net Sat, 06 Jun 2009 14:50:23 +0000 http://code.openark.org/blog/?p=614#comment-2276 [...] para utilizar el parámetro innodb_per_table en MySQL, en Openark. (en [...] [...] para utilizar el parámetro innodb_per_table en MySQL, en Openark. (en [...]

]]>