我们应该查看哪些mySQL服务器变量以及哪些阈值对于以下问题场景具有重要意义:
对于每种情况,建议使用哪些解决方案来改进它们,而不是获得更好的硬件或将数据库扩展到多个服务器？
这是一个复杂的领域。影响这三个类别的“阈值”有很多重叠。
如果您的操作受到 CPU 限制而出现问题，那么您肯定需要查看： (a) 数据库的结构 - 是否完全规范化。错误的数据库结构会导致复杂的查询影响处理器。(b) 您的索引 - 查询所需的一切都已充分索引。缺乏索引会对处理器和内存造成非常严重的打击。要检查索引，请执行“解释...您的查询”。结果解释中的任何行表明它没有使用索引，您需要仔细查看，如果可能，添加索引。(c) 尽可能使用准备好的语句。这些可以使 CPU 免于进行大量运算。(d) 使用更好的编译器并进行适合您的 CPU 的优化。这是专门为专用类型设计的，但它可以让你到处收集额外的百分比。
如果您的操作在读取绑定时遇到问题 (a) 确保在可能的情况下进行缓存。检查 query_cache_limit 和 query_cache_size 的配置变量。这不是一个神奇的解决办法，但提高这些可以有所帮助。(b) 与上面一样，检查您的索引。好的索引可以减少需要读取的数据量。
如果您的操作被写入绑定时遇到问题 (a) 查看您是否需要当前拥有的所有索引。索引固然很好，但它们改善查询时间的代价是，维护这些索引可能会影响写入数据和保持数据最新所花费的时间。通常，如果有疑问，您需要索引，但有时您对快速写入表比从表中读取更感兴趣。(b) 尽可能使用 INSERT DELAYED 对数据库的写入进行“排队”。请注意，这不是一个神奇的修复方法，而且通常不合适，但在适当的情况下可能会有所帮助。(c) 检查同时大量读取和写入的表，例如不断更新访问者会话数据并且读取同样多的访问列表。优化表的读取和写入很容易，但实际上不可能设计一个同时擅长读取和写入的表。如果遇到这种情况并且它是瓶颈，请考虑是否可以拆分其功能或将使用该表的任何复杂操作移动到可以定期作为块更新的临时表。
请注意，上面唯一具有重大影响的内容是良好的查询设计/索引。除此之外，您还想开始考虑更好的硬件。特别是，您可以从 RAID-0 阵列中获得很多好处，它对于写入限制问题没有太大作用，但可以在读取限制问题上发挥作用。它可能是一个相当便宜的解决方案，可以带来巨大的提升。
您还错过了清单上的两项。
内存限制。如果您遇到内存问题，那么您必须检查所有可以有效索引的内容是否都已索引。如果由于某种原因您使用大量与数据库的离散连接，您还可以考虑更大的连接池。
网络绑定。如果您遇到网络限制问题……那么您可能没有遇到网络限制问题，但如果是的话，您需要另一个网卡或更好的网络。
请注意，分析数据库性能的一种便捷方法是打开 log_slow_queries 选项并将 long_query_time 设置为 0 以获取所有内容，或者设置为 0.3 或类似的值以捕获可能阻碍数据库运行的任何内容。您还可以打开 log-queries-not-using-indexes 以查看是否显示任何有趣的内容。请注意，这种日志记录可能会杀死繁忙的实时服务器。在开发盒上尝试一下即可开始。
希望这有一些帮助。我对任何人对上述内容的评论感兴趣。