一个诊断案例（）
如果读者一直顺着我们前面的思路读下来可能还会有一些疑问在这里我们可以稍微解释一下（我们在本章引用的方法在审阅的时候已经检查过一遍）
为什么我们不一开始就优化慢查询？
因为问题不在于慢查询而是太多连接的错误当然因为慢查询太多查询的时间过长而导致连接堆积在逻辑上也是成立的但也有可能是其他原因导致连接过多如果没有找到问题的真正原因那么回头查看慢查询或其他可能的原因看是否能够改善是很自然的事情注但这样做大多时候会让问题变得更糟如果你把一辆车开到机械师那里抱怨说有异响假如机械师没有指出异响的原因也不去检查其他的地方而是直接做了四轮平衡和更换变速箱油然后把账单扔给你你也会觉得不爽的吧？
但是查询由于糟糕的执行计划而执行缓慢不是一种警告吗？
在事故中确实如此但慢查询到底是原因还是结果？在深入调查前是无法知晓的记住在正常的时候这个查询也是正常运行的一个查询需要执行filesort 和创建临时表并不一定意味着就是有问题的尽管消除filesort 和临时表通常来说是最佳实践
通常的最佳实践自然有它的道理但不一定是解决某些特殊问题的灵丹妙药比如说问题可能是因为很简单的配置错误我们碰到过很多这样的案例问题本来是由于错误的配置导致的却去优化查询这不但浪费了时间也使得真正问题被解决的时间被拖延了
如果缓存项被重新生成了很多次是不是会导致产生很多同样的查询呢？这个问题我们确实还没有调查到如果是多线程重新生成同样的缓存项那么确实有可能导致产生很多同样的查询（这和很多同类型的查询不同比如WHERE 子句中的参数可能不一样）注意到这样会刺激我们的直觉并更快地带我们找到问题的解决方案
每秒有几百次SELECT 查询但只有五次UPDATE怎么能确定这五次UPDATE 的压力不会导致问题呢？
这些UPDATE 有可能对服务器造成很大的压力我们没有将真正的查询语句展示出来因为这样可能会将事情搞得更杂乱但有一点很明确某种查询的绝对数量不一定有意义
I/O 风暴最初的证据看起来不是很充分？
是的确实是这样有很多种解释可以说明为什么一个这么小的数据库可以产生这么大量的写入磁盘或者说为什么磁盘的可用空间下降得这么快这个问题中使用的MySQL 和GNU/Linux 版本都很难对一些东西进行测量（但不是说完全不可能）
尽管在很多时候我们可能扮演魔鬼代言人的角色但我们还是以尽量平衡成本和潜在的利益为第一优先级越是难以准确测量的时候成本/ 收益比越攀升我们也更愿意接受不确定性
之前说过数据库过去从来没出过问题是一种偏见吗？
是的这就是偏见如果抓住问题很好 如果没有也可以是证明我们都有偏见的很好例子
至此我们要结束这个案例的学习了需要指出的是如果使用了诸如New Relic 这样的剖析工具即使没有我们的参与也可能解决这个问题
返回目录高性能MySQL
编辑推荐
ASPNET MVC 框架揭秘
Oracle索引技术
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
