我意味每个词的它。 我在几天连续看以后MySQL日志发现了这个简单的配置技巧(mytop)，上面，缓慢的日志询问，调试地狱在应用外面，读吨MySQL优化技巧(和拉扯我在失望的剩余的头发)在网。 MySQL从MySQL的优化技巧不提及它。 仍然这个唯一技巧解决了所有我的MySQL头疼和性能问题。 这我面对的某些问题：

我强有力的专用服务器常常地消耗100% CPU甚而与适度装载。
与吨优化和索引，我发现我的服务器懒惰CPU去0%。 主要资源消费者是MySQL。 最坏的部分是拒绝的MySQL担当新的请求所有螺纹是被用尽的等待(为了某一奇迹能发生？)。

那个声音知交中的任一个？ 然后读为血污技术解释和技巧。

BTW ： 我最初的反应对这样问题是标准一个。 我看MySQL大师大师复制(这比WordPress.com为它的站点做)的主人奴隶的复制好照料增加的装载。 幸运地这种唯一配置变化比以前做我的服务器采取至少10倍更多装载。

在缺省MySQL配置(与是缺省引擎)的MyISAM引擎快速的赛跑甚而插入物或更新声明在与全部的桌里可能导致严肃的瓶颈读(选择声明)。

MySQL执行插入物&更新声明以重要性。 并且插入物&更新声明要求要求甚而桌读的桌锁(为MYISAM引擎) (精选的声明)完成，在插入物&更新被执行之前。 这可能导致等待在插入物或更新声明之后的精选的声明的长时间的推迟，也许本身花最小的时间执行，等待现有的长期的SQL精选的声明完成。 那么甚而一次唯一插入物或更新能减速一个沉重被装载的数据库在变化莫测的时刻。

一种解答将使用插入物被延迟的声明造成插入物声明跑在队列的低优先级。 更新的相似的声明不是可利用的。 并且在我们的实验它证明显着下等对我其次将描述的解答。 因此您是否是准备好？

我建议您增加在/etc/my.cnf (MYSQL在Linux的配置文件的以下线; 搜寻在Windows的my.cnf)激烈地减少可能性的这样瓶颈，如上所述，并且改进沉重被装载的服务器表现：

max_write_lock_count = 1

通过开始与低值的mysqld max_write_lock_count系统变量的您强迫MySQL临时地举起所有的优先权等待桌的精选的声明，在插入物的一个具体数字对桌的发生之后。 这在一定数量以后允许读锁写锁。 那是否是确切？

最后结果是这种简单的配置可能激烈地改进您的MySQL表现，特别是如果您的服务器沉重被装载。 您应该尝试此优选的所有沉重被装载的MySQL服务器包括但不限于WordPress例如站点数据库。

更新： 使用InnoDB被建议的某些人民。 然而InnoDB不是一个魔法。 在许多情况下它可以是更慢的。 MyISAM是tradionally与二个警告的更加快速的数据库-锁问题如上所述和缺乏交易的桌。 以上述固定，当您不需要交易时，我们演讲再做出它更好的选择的MyISAM的核心性能问题。 并且象WordPress的一些软件不支持InnoDB。