商業需求對性能的影響(MySQL)

應用系統每個功能的設計初衷確定都是爲用戶提供某種用戶，或者知足用戶某種需求，可是，並非每個功能在最後都能很成功，甚至有些功能可能在整個系統中多此一舉的。不只沒有爲用戶提升任何體驗度，也沒有爲用戶改進多少功能易用性，反而成了一個累贅，帶來資源浪費。
不合理的需求形成資源投入產出比太低
需求是否合理不少時候並是容易界定，尤爲是對技術人員來講，可能更難以肯定。即便指出，也不必定會被產品經理承認。那做爲技術人員怎麼來證實一個需求是否合理呢？
第一， 每次產品經理提出新項目（或者功能需求）的時候，應該要求他們同時給出該項目的預期收益的量化指標，以備項目上線後統計評估投入產出比率；
第二， 在項目的進行過程當中，應該詳細記錄全部的資源投入，包括人力投入、硬件設施的投入，以及其餘任何項目相關的資源投入；
第三， 項目（或者功能需求）上線以後應該及時經過收集相關數據統計項目的實際收益值，以便計算投入產出比率的時候使用；
第四， 相關部門應該儘量設計出一個項目（或者功能需求）投入產出比率的計算規則。在項目上線一段時間以後，經過項目實際收益統計數據和項目的投入資源量，計算出整個項目的實際投入產出值，並公佈給全部參與項目的部門知曉，同時存放以備後查。
有了實際的投入產出比率，就能夠和立項之初產品經理的預期投入產出比率作比較，以斷定這個項目作得是否值得。並且在積累了較多的項目投入產出比率以後，能夠根據歷史數據分析出一個項目合理的投入產出比率。這樣，在項目立項之初，就能夠斷定出產品經理的預期投入產出比率是否合理，項目是否真的有必要進行。
有了實際的投入產出比率以後，咱們還能夠拿出數據給管理層可圈可點，讓他知道功能並非越多越好，讓他知道有些功能是應該撤下來的，即便撤下該功能可能還需要投入很多資源。
實際上，通常來講，在產品開發及運營部門內部都會作上述這些事情。但更多時候可能只是一種形式化的過程。在有些比較規範的公司或許仍是完成了大部分流程，可是要麼數據不公開，要麼公開給其餘部門的數據存在必定誤差，不具有真實性。
爲何會這樣？由於涉及部門之間的利益和業績衝突問題。某些產品經理老是但願儘量地讓用戶以爲本身設計的產品功能齊全，讓老闆以爲本身作了不少事情。可是不多關心作一個功能所帶來的成本投入，或者說不是特別關心這一點。並且不少時候他們也並不太理解技術複雜度給產品帶來的負面影響。
這裏拿一個看上去很簡單的功能來分析一下。
需求： 一個論壇帖子總量的統計
附加需求： 實時更新
在不少人看來，這個功能很是容易實現，執行一條select count(*)的query不就能夠獲得結果了麼？是的，確實只須有一個簡單的query就能夠獲得結果。可是，若是咱們採用的不是MyISAM存儲引擎，而是InnoDB存儲引擎，那麼你們能夠試想一下，若是存放帖子的表中已經有上千萬帖子，執行這條query語句須要多少成本？恐怕再好的硬件設備都很難高效地完成這樣一次查詢吧。若是訪問量再大一點，那還有人以爲這是一件簡單的事情麼？
既然這樣查詢不行，那是否是該專門爲這個功能建一個表？這個表裏只有一個字段，一條記錄，就是存放這個統計量，每次有了新的帖子，都將這個值增長1，這樣每次都只需要查詢這個表就能夠獲得結果了，這個效率確定可以知足要求。確實，查詢效率可以知足要求，但是若是系統帖子產生得很快，在高峯時期可能每秒會有幾十甚至上百個帖子產生，恐怕這個統計表又要成爲你們的噩夢了。要麼由於爆發的問題形成統計結果的不許確，要麼由於鎖資源爭用嚴重形成總體性能大幅度地降低。
其實這個問題的焦點不該該是實現這個功能的技術細節，而是這個功能的附加要求「實時更新」。當一個論壇的帖子數量很大時，到底有多少人會關注這個統計數據是不是實時變化的？有多少人在意這個數據庫在短期內的不精確性？我想恐怕不會有人會傻傻地盯着這個統計數字並追究當本身發了一個帖子回頭刷新頁面時這個統計數字是否加1？即便明明白白地告訴用戶這個統計數據每隔必定時間段更新一次，那又怎樣？難道會有不少用戶就此很不爽麼？
只要去掉了這個「實時更新」的附加條件，就能夠很是容易實現這個功能了。就像以前所提的的，建立一個統計表，而後經過一個定時任務每隔必定時間就去更新一次統計值。這樣既能夠解決統計值查詢的效率問題，又能保證不影響新發帖的效率，一箭雙鵰。
實際上，在應用的系統中還有不少相似功能點能夠優化。如某些場合的列表頁面參與列表的數據量達到必定數量級別後，徹底能夠不用準確地顯示這個列表共有多少條信息，總共分了多少頁，只須要一個大概的估計值或一個時間段以前的統計值。這樣就省略了分頁程序在分之前實時計算(COUNT)出知足條件的記錄數。
其實，在不少應用系統中，實時和準實時，精確與基本準確，在不少地方所帶來是性能消耗多是幾個性能的差異。在系統性能優化中，應該儘可能分析出哪些能夠不實時和不徹底精確，並做出一些相應的調整，這會給你們帶來意想不到的巨大性能提高。
無用功能堆積使系統過分複雜，影響總體性能 不少時候，爲系統增長某個功能可能並不需要花費太多的成本，而要想將一個已經運行了一段時間的功能從原有系統中撤下來倒是很是困難的。 首先，對於開發部門，可能要從新整理不少的代碼，找出與增長該功能所編寫的代碼可能有交集的其餘功能點，刪除沒有關聯的代碼，修改有關聯的。 其次，對於測試部門，因爲功能的變更，必需要回歸測試全部相關的功能點是否正常。可能因爲界定困難，不得不將回歸範圍擴展到很大，測試工做量也很大。 最後，對全部參與撤除下線某個功能是相關工做者來講，此舉沒法帶來任何實質性的收益，而偏偏相反，帶來的只多是風險。 因爲上面的這幾個因素，可能不多會有公司會有很完善的項目（或者功能）下線機制，也不多有公司能作到及時將系統中某些不合適的功能下線。因此，咱們所面對個應用系統可能老是愈來愈複雜，愈來愈龐大，短時間內的複雜也許並沒有太大問題，可是隨着時間的積累，所面對的系統就會變得臃腫。不只維護困難，性能也會愈來愈差。尤爲是有些並不合理的功能，在設計之初或是剛上線的時候因爲數據較小，不會帶來多少性能損耗。可隨着時間的推移，數據庫中的數據量愈來愈大，數據檢索愈來愈困難，整個系統帶來的資源消耗也就愈來愈大。 並且，並且系統複雜度的不斷增長，給後續其餘功能的開發帶來了實現的複雜度，不少原本很簡單的功能，可能由於系統的複雜而不得不增長更多的邏輯判斷，形成系統應用程序的計算量增長，自己性能就會受到影響。而若是這些邏輯判斷還須要與數據庫交互，並經過持久化的數據來完成，那所帶來的性能損失就更大，對整個系統的性能影響也就更大了。