mysql - 如何预测MySQL的临界点？

Question

我在一个大型 Web 应用程序上工作，该应用程序使用带有 InnoDB 表的 MySQL 5.0 数据库。在过去的几个月里，我们经历了两次以下情况:

1. 数据库服务器运行良好数周，负载低且查询缓慢。
2. 以前运行很快的频繁执行的查询会突然开始运行得很慢。
3. 数据库负载激增，网站挂起。

这两种情况的解决方案都是在慢查询日志中找到慢查询，并在表上创建新索引以加快速度。应用索引后，数据库性能恢复正常。

最令人沮丧的是，在这两种情况下，我们都没有对即将到来的厄运发出警告；我们所有的监控系统(例如，系统负载图、CPU 使用率、查询执行率、慢查询)都告诉我们数据库服务器运行状况良好。

问题 #1:我们如何预测这些类型的临界点或完全避免它们？

我们不经常做的一件事是运行 OPTIMIZE TABLE 或 ANALYZE TABLE。我们很难找到关于手动执行这些操作的频率(如果有的话)的良好经验法则。 (由于这些命令锁定表，我们不想不加选择地运行它们。)这些场景听起来像是未优化表的结果吗？

问题 #2:我们应该手动运行 OPTIMIZE 还是 ANALYZE？如果是，多久一次？

有关该应用程序的更多详细信息:数据库使用模式约为 95% 读取，5% 写入；数据库每秒执行大约 300 个查询；在这两种情况下，慢查询中使用的表是相同的，并且有数十万条记录。

Answer 1

MySQL 性能博客是一个很棒的资源。即 this帖子涵盖了正确调整 InnoDB 特定参数的基础知识。

我还发现 MySQL Reference Manual 的 PDF 版本是必不可少的。 Chapter 7 covers general optimization , 和 section 7.5涵盖您可以尝试的特定于服务器的优化。

从服务器的声音来看，query cache可能对您有巨大的值(value)。

引用手册还为您提供了一些有关慢速查询、缓存、查询优化，甚至是使用索引的磁盘搜索分析的详细信息。

可能值得花时间研究多主复制，允许您完全锁定一台服务器并运行优化/分析，而不会影响性能(因为 95% 的查询是读取，另一台服务器可以管理写得很好)。

第 12.5.2.5 节详细介绍了 OPTIMIZE TABLE，第 12.5.2.1 节详细介绍了 ANALYZE TABLE。

更新您的编辑/重点:

问题 #2 很容易回答。来自引用手册:

优化:

OPTIMIZE TABLE should be used if you have deleted a large part of a table or if you have made many changes to a table with variable-length rows. [...] You can use OPTIMIZE TABLE to reclaim the unused space and to defragment the data table.

然后分析:

ANALYZE TABLE analyzes and stores the key distribution for a table. [...] MySQL uses the stored key distribution to decide the order in which tables should be joined when you perform a join on something other than a constant. In addition, key distributions can be used when deciding which indexes to use for a specific table within a query.

OPTIMIZE 适合在有空的时候运行。 MySQL 围绕已删除的行进行了很好的优化，但是如果您要从表中删除 20GB 的数据，那么运行它可能是个好主意。在大多数情况下，它绝对不是获得良好性能所必需的。

ANALYZE 更为关键。如前所述，当涉及到几乎任何查询时，为 MySQL 提供所需的表数据(由 ANALYZE 提供)非常重要。它应该在共同的基础上运行。

问题 #1 更像是一个技巧。发生这种情况时，我会非常仔细地观察服务器，即磁盘 I/O。我敢打赌，您的服务器正在破坏您的交换或 (InnoDB) 缓存。在任何一种情况下，它都可能与查询、调整或负载相关。未优化的表可能会导致这种情况。如前所述，运行 ANALYZE 可以极大地提高性能，并且可能也会有所帮助。