我运行一个虚拟服务器上有一个Owncloud安装。 现在Owncloud的问题就是它现在开发的方式，每次file upload都会导致一点MySql开销。
因此，尽可能地优化MySql数据库非常重要。 有很多人在网上推荐一个非常大的innodb_buffer_pool_size达到4,5或更多的GByte，有人甚至说到70到80％的总ram，嗯？
好吧，但是很less有人介意叫做innodb_buffer_pool_instances的第二个参数
所以让我们看看我的情况。 我的虚拟机资源有限。 这意味着6400 GByte总RAM，并在正常模式下约3000（由libvirt处理）。 因此，如果我设置innodb_buffer_pool_instances超过1，或者让它在新的MySql服务器的默认configuration（8或者什么）意味着（只要我明白了这一点）在最坏的情况下，例如innodb_buffer_pool_instances = 4和innodb_buffer_pool_size = 4 =>在最大情况下，4 * 4 = 16 GB RAM。 什么会导致交换磁盘的不良使用，以及MySql innodb缓冲区的每个交换使用对于任何性能都是一种矫枉过正。
结论很容易。 可用的缓冲区大小必须小于至less70％的可用ram，其余可能需要php，apache和系统本身。
那么更好的决策是什么？ 只有一个可能的innodb_buffer_pool_instances但是一个非常大的innodb_buffer_pool_size或更好的一个更小的innodb_buffer_pool_size ，因此如果需要，同时更多的innodb_buffer_pool_instances 。
我的服务器最多使用10到30人左右。
innodb_buffer_pool_instances：
除非innodb_buffer_pool_size很less，否则不能看到它的效果，将缓冲池划分成不同的实例可以提高效率。 这也是对innodb_buffer_pool_instance一个调整实践，以便每个缓冲池实例至less为1GB。
例如，如果innodb_buffer_pool_size = 4GB，那么，innodb_buffer_pool_instances = 4
MySQL 5.6的默认值是8
innodb_buffer_pool_size：
innodb_buffer_pool_size应该是内存的80％
这个想法只适用于没有其他进程在运行的专用MySQL服务器。 另一方面缓冲池不应该less一些，如果有足够的RAM。 另外，需要检查系统是否是64/32位。