一個診斷案例（）
如果讀者一直順著我們前面的思路讀下來可能還會有一些疑問在這裡我們可以稍微解釋一下（我們在本章引用的方法在審閱的時候已經檢查過一遍）
為什麼我們不一開始就優化慢查詢？
因為問題不在於慢查詢而是太多連接的錯誤當然因為慢查詢太多查詢的時間過長而導致連接堆積在邏輯上也是成立的但也有可能是其他原因導致連接過多如果沒有找到問題的真正原因那麼回頭查看慢查詢或其他可能的原因看是否能夠改善是很自然的事情注但這樣做大多時候會讓問題變得更糟如果你把一輛車開到機械師那裡抱怨說有異響假如機械師沒有指出異響的原因也不去檢查其他的地方而是直接做了四輪平衡和更換變速箱油然後把賬單扔給你你也會覺得不爽的吧？
但是查詢由於糟糕的執行計劃而執行緩慢不是一種警告嗎？
在事故中確實如此但慢查詢到底是原因還是結果？在深入調查前是無法知曉的記住在正常的時候這個查詢也是正常運行的一個查詢需要執行filesort 和創建臨時表並不一定意味著就是有問題的盡管消除filesort 和臨時表通常來說是最佳實踐
通常的最佳實踐自然有它的道理但不一定是解決某些特殊問題的靈丹妙藥比如說問題可能是因為很簡單的配置錯誤我們碰到過很多這樣的案例問題本來是由於錯誤的配置導致的卻去優化查詢這不但浪費了時間也使得真正問題被解決的時間被拖延了
如果緩存項被重新生成了很多次是不是會導致產生很多同樣的查詢呢？這個問題我們確實還沒有調查到如果是多線程重新生成同樣的緩存項那麼確實有可能導致產生很多同樣的查詢（這和很多同類型的查詢不同比如WHERE 子句中的參數可能不一樣）注意到這樣會刺激我們的直覺並更快地帶我們找到問題的解決方案
每秒有幾百次SELECT 查詢但只有五次UPDATE怎麼能確定這五次UPDATE 的壓力不會導致問題呢？
這些UPDATE 有可能對服務器造成很大的壓力我們沒有將真正的查詢語句展示出來因為這樣可能會將事情搞得更雜亂但有一點很明確某種查詢的絕對數量不一定有意義
I/O 風暴最初的證據看起來不是很充分？
是的確實是這樣有很多種解釋可以說明為什麼一個這麼小的數據庫可以產生這麼大量的寫入磁盤或者說為什麼磁盤的可用空間下降得這麼快這個問題中使用的MySQL 和GNU/Linux 版本都很難對一些東西進行測量（但不是說完全不可能）
盡管在很多時候我們可能扮演魔鬼代言人的角色但我們還是以盡量平衡成本和潛在的利益為第一優先級越是難以准確測量的時候成本/ 收益比越攀升我們也更願意接受不確定性
之前說過數據庫過去從來沒出過問題是一種偏見嗎？
是的這就是偏見如果抓住問題很好 如果沒有也可以是證明我們都有偏見的很好例子
至此我們要結束這個案例的學習了需要指出的是如果使用了諸如New Relic 這樣的剖析工具即使沒有我們的參與也可能解決這個問題
返回目錄高性能MySQL
編輯推薦
ASPNET MVC 框架揭秘
Oracle索引技術
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
From:http://tw.wingwit.com/Article/program/MySQL/201311/29694.html
