优化 MySQL

Question

根据这篇文章，看起来我在 MySQL 优化方面遇到了一些严重的问题。

不幸的是，我不知道从哪里开始！

我正在运行基于 DirectAdmin 的 CentOS 专用服务器。它是具有 8Gb RAM 的英特尔四核 3Ghz。我在上面运行了许多网站，但我相信只有我的主网站才能获得真正的流量。

我担心的网站每周有大约 30,000 名独立访问者/250,000 次点击。这是一个基于 WordPress 的网站。

我my.cnf的基本上是空的。我增加了max_connections处理初始问题的能力（根据之前链接的帖子，网站不断出现“数据库最大连接数”错误），仅此而已。

我尝试在服务器上运行两个脚本来确定如何优化我的设置。其中一个不起作用，但另一个建议如下：

• 支持查询缓存但未启用；也许你应该设置query_cache_size
• 您有 11025 个查询，其中连接无法正确使用索引；您应该启用“log-queries-not-using-indexes”，然后在慢查询日志中查找非索引连接。
• 您总共有834 张桌子；您有528 张空桌；当前table_cache 命中率为 8%，而132% 的表缓存正在使用中；你应该增加你的table_cache
• 你可能应该增加你的table_definition_cache价值。
• 当前锁定等待比率 = 1 : 529；您可能会受益于 InnoDB 的选择性使用。
• 当前max_heap_table_size = 16 M；当前tmp_table_size = 16 M ; 在107071 个临时表中，25% 是在磁盘上创建的；也许您应该增加 tmp_table_size 和/或 max_heap_table_size 以减少基于磁盘的临时表的数量
• 1145245 个中有1290个花费的时间超过 2.000000 秒。去完成
• 当前最大连接数 = 500；当前threads_connected = 501; 你应该提高 max_connections

可以在此处找到完整的源代码。

不幸的是，我真的不知道这有什么作用，我也不想盲目地走进去。

有没有人对优化我的 MySQL 安装有任何建议？

Answer 1

从 DB 的角度来看，而不是 WordPress。

执行摘要

对于您的优化器脚本生成的每个建议，请查看相应的 MySQL 文档以查看它是否会影响您的设置。然后my.conf一点一点地调整你的。

您的总体目标是让 MySQL 尽可能多地加载到内存中，而不是访问磁盘。因此，增加各种缓存可能会有所帮助。只要您不超过服务器中的物理内存（您需要考虑服务器上运行的其他进程）。然后，确保您的表被适当地索引。

您的具体问题

但是要解决您列出的每个项目：

支持查询缓存但未启用；也许你应该设置 query_cache_size

该查询缓存就像是select语句的大哈希表- >结果-表。MySQL 检查缓存中是否存在相同的查询，并返回缓存的结果，而无需重新运行查询。如果启用它，请运行SHOW VARIABLES以查看它的使用情况（拥有未使用的巨大缓存只是浪费内存）。我对查询缓存的体验是，理论上它看起来非常好，但在实践中并没有提供太多帮助。

您有 11025 个查询，其中连接无法正确使用索引；您应该启用“log-queries-not-using-indexes”，然后在慢查询日志中查找非索引连接。

索引决定了数据库的成败。启用慢查询日志并用于EXPLAIN查看哪些查询未使用索引。先修复慢的。

您总共有 834 张桌子；您有 528 张空桌；当前 table_cache 命中率为 8%，而 132% 的表缓存正在使用中；你应该增加你的 table_cache

MySQL ISAM数据库以成对（我认为）文件的形式存在于磁盘上，但 MySQL 不会一直打开它们，只有最近使用过的。该table_cache的设置控制多少文件，将保持开放。这似乎与连接数有关，因此请小心将其设置得太高，但似乎您有可用的内存堆栈，因此请增加此值直到缓存所有表。

当前锁定等待比率 = 1 : 529; 您可能会受益于 InnoDB 的选择性使用。

MyISAM数据表是伟大的阅读，但每当你UPDATE，INSERT或者DELETE从他们的MySQL锁定整个表。因此，例如，如果您有一个Page表，该表的HitCount字段在加载页面时递增，则整个Page表将被锁定，并且没有其他连接可以从中读取。我见过一些特别讨厌的读/写查询组合，它们会将表锁定数分钟甚至数小时！有效地杀死网站。

InnoDB 的读取速度没有那么快，但支持更细粒度的写入操作（只锁定正在更新的一条记录）。所以更适合写入更频繁的表。将具有大量UPDATE,INSERT和DELETE操作的表转换为 InnoDB 可能会减少锁定并提高性能。出于这个原因，许多使用 MySQL 的应用程序默认使用 InnoDB。

我认为您需要删除旧的 MyISAM 表并将它们重新创建为 InnoDB，因此会涉及停机时间。

显然ALTER TABLE，更改引擎类型只需要一个语句。尽管需要全表锁定，但您将有一些时间无法运行查询。

我不知道 WordPress 是否采用 InnoDB 或 MyISAM 表。请在更改表格引擎之前检查 WordPress 。

当前 max_heap_table_size = 16 M；当前 tmp_table_size = 16 M；在 107071 个临时表中，25% 是在磁盘上创建的；也许您应该增加 tmp_table_size 和/或 max_heap_table_size 以减少基于磁盘的临时表的数量

MySQL 需要内存来进行排序 (ORDER BY)、JOIN 和其他涉及大块数据的操作，但只能达到一定的限制，在此限制之后，操作会溢出到磁盘上（这样一个巨大的 ORDER BY 就不会用完千兆字节的内存，可以更好地用于做其他事情）。增加max_heap_table_size并tmp_table_size意味着在慢速磁盘上运行的操作更少，在快速内存中运行更多（关于这些变量的讨论）。对于大多数情况，64M 应该足够大，而使这些太大意味着您只是在浪费内存。

1145245 个中有 1290 个花费的时间超过 2.000000 秒。去完成

使用慢查询日志找出这些慢查询是什么。尽管这个比率 (0.11%) 非常低，但可能有一些非常慢的查询会导致更大的问题。

当前最大连接数 = 500；当前threads_connected = 501; 你应该提高 max_connections

一旦你有更多的threads_connected比max_connections新的连接将被拒绝。增加max_connections（正如您已经完成的那样）。

如您所见，在不知道 WordPress 生成什么样的查询的情况下，做什么并不总是显而易见的。