我在一个使用带有InnoDB表的MySQL 5.0数据库的大型Web应用程序上工作。在过去几个月中，我们经历了以下两种情况：
两种情况下的解决方案是在慢查询日志中找到慢查询并在表上创建新索引以加快速度。应用索引后，数据库性能恢复正常。
最令人沮丧的是，在这两种情况下，我们都没有对即将到来的厄运发出警告;我们所有的监控系统（例如，系统负载，CPU使用率，查询执行率，慢查询的图表）都告诉我们数据库服务器运行状况良好。
问题＃1：我们如何预测这些临界点或完全避免这些临界点？
我们没有做任何规律性的事情是运行OPTIMIZE TABLE或ANALYZE TABLE。我们很难找到关于手动执行这些操作的频率（如果有的话）的好经验法则。 （由于这些命令是LOCK表，我们不想无差别地运行它们。）这些场景听起来像是未经优化的表的结果吗？
问题2：我们应该手动运行OPTIMIZE还是ANALYZE？如果是这样，多久一次？
有关应用程序的更多详细信息：数据库使用模式约为95％读取，5％写入;数据库执行大约300个查询/秒;慢速查询中使用的表在两种情况下都是相同的，并且有数十万条记录。
答案 0 :(得分：7)
MySQL性能博客是一个很棒的资源。即，this帖子涵盖了正确调整InnoDB特定参数的基础知识。
我还发现MySQL Reference Manual的PDF版本至关重要。 Chapter 7 covers general optimization和section 7.5涵盖了您可以使用的特定于服务器的优化。
根据您服务器的声音，query cache可能具有IMMENSE值。
参考手册还为您提供了一些有关慢速查询，缓存，查询优化以及带索引的磁盘搜索分析的详细信息。
您可能值得花时间研究多主复制，允许您完全锁定一台服务器并运行OPTIMIZE / ANALYZE，而不会影响性能（因为95％的查询是读取，另一台服务器可以管理写得很好）。
第12.5.2.5节详细介绍了OPTIMIZE TABLE，12.5.2.1详细介绍了ANALYZE TABLE。
更新您的修改/重点：
问题＃2 很容易回答。参考手册：
OPTIMIZE：
如果删除了表的大部分，或者对具有可变长度行的表进行了许多更改，则应使用OPTIMIZE TABLE。 [...]您可以使用OPTIMIZE TABLE回收未使用的空间并对数据表进行碎片整理。
分析：
ANALYZE TABLE分析并存储表的密钥分发。 [...] MySQL使用存储的密钥分发来决定在对常量以外的其他内容执行连接时应该连接表的顺序。此外，在决定用于查询中特定表的索引时，可以使用密钥分发。
当你有空闲时间时，OPTIMIZE很适合运行。 MySQL可以很好地优化已删除的行，但是如果你从表中删除20GB的数据，可能运行它是个好主意。在大多数情况下，绝对不需要良好的性能。
分析更为关键。如上所述，当涉及到几乎任何查询时，将所需的表数据提供给MySQL（随ANALYZE提供）非常重要。这是应该在共同基础上运行的东西。
问题＃1 更多的是一招。发生这种情况时，我会仔细观察服务器，即磁盘I / O.我敢打赌，你的服务器正在颠覆你的交换或（InnoDB）缓存。在任何一种情况下，它可能是查询，调整或负载相关。未经优化的表可能会导致这种情况。如上所述，运行ANALYZE可以极大地帮助提高性能，也可能会有所帮助。
答案 1 :(得分：1)
我还没有找到任何预测MySQL“引爆点”的好方法 - 而且我遇到了一些问题。
话虽如此，我发现临界点与表格大小有关。但不仅仅是原始表的大小，而是“感兴趣的区域”对查询的大小。例如，在一个包含超过300万行和大约40列的表中，大约四分之三的整数，大多数基于索引可以轻松选择其中一部分的查询都很快。但是，当一个索引列上的查询中的一个值意味着三分之二的行现在“有趣”时，查询现在比正常情况慢大约5倍。课程：尝试排列数据，以便不需要进行扫描。
但是，此类行为现在可以为您提供查找大小。此大小将在很大程度上取决于您的服务器设置，MySQL服务器变量以及表的架构和数据。
同样地，我看到报告查询在合理的时间（约45秒）内运行（如果周期为两周），但如果周期延长到四周则需要半小时。
答案 2 :(得分：0)
使用slow query log可以帮助您缩小要优化的查询范围。
对于时间紧迫的查询，有时最好通过使用提示来保持稳定的计划。
答案 3 :(得分：0)
听起来你有一个令人沮丧的情况，也许不是最好的代码审查流程和开发环境。
每当您向代码添加新查询时，您需要检查它是否已准备好相应的索引并添加具有代码版本的索引。
如果你不这样做，你的第二个选择是不断监控慢查询日志，然后击败开发人员;我的意思是去添加索引。
可以选择启用未使用对您有用的索引的查询记录。
如果有一些查询“工作并停止工作”（但是“正在使用和索引”），那么查询可能首先不是很好（索引中的基数低;无效的连接;。 ..）以及在添加时仔细评估查询的第一条规则将适用。
对于问题＃2 - 在InnoDB上，“analyze table”基本上是免费运行的，所以如果你有不好的连接性能，那么运行它并没有什么坏处。除非表中键的平衡发生很大变化，否则它不太可能有所帮助。它几乎总是归结为糟糕的查询。 “optimize table”重建InnoDB表;根据我的经验，相对较少的是，它足以值得让持续时间内表不可用的麻烦（或在运行时执行主 - 主故障转移）。