商业需求对性能的影响(MySQL)

应用系统每个功能的设计初衷确定都是为用户提供某种用户，或者知足用户某种需求，可是，并非每个功能在最后都能很成功，甚至有些功能可能在整个系统中多此一举的。不只没有为用户提升任何体验度，也没有为用户改进多少功能易用性，反而成了一个累赘，带来资源浪费。
不合理的需求形成资源投入产出比太低
需求是否合理不少时候并是容易界定，尤为是对技术人员来讲，可能更难以肯定。即便指出，也不必定会被产品经理承认。那做为技术人员怎么来证实一个需求是否合理呢？
第一， 每次产品经理提出新项目（或者功能需求）的时候，应该要求他们同时给出该项目的预期收益的量化指标，以备项目上线后统计评估投入产出比率；
第二， 在项目的进行过程当中，应该详细记录全部的资源投入，包括人力投入、硬件设施的投入，以及其余任何项目相关的资源投入；
第三， 项目（或者功能需求）上线以后应该及时经过收集相关数据统计项目的实际收益值，以便计算投入产出比率的时候使用；
第四， 相关部门应该尽量设计出一个项目（或者功能需求）投入产出比率的计算规则。在项目上线一段时间以后，经过项目实际收益统计数据和项目的投入资源量，计算出整个项目的实际投入产出值，并公布给全部参与项目的部门知晓，同时存放以备后查。
有了实际的投入产出比率，就能够和立项之初产品经理的预期投入产出比率作比较，以断定这个项目作得是否值得。并且在积累了较多的项目投入产出比率以后，能够根据历史数据分析出一个项目合理的投入产出比率。这样，在项目立项之初，就能够断定出产品经理的预期投入产出比率是否合理，项目是否真的有必要进行。
有了实际的投入产出比率以后，咱们还能够拿出数据给管理层可圈可点，让他知道功能并非越多越好，让他知道有些功能是应该撤下来的，即便撤下该功能可能还需要投入很多资源。
实际上，通常来讲，在产品开发及运营部门内部都会作上述这些事情。但更多时候可能只是一种形式化的过程。在有些比较规范的公司或许仍是完成了大部分流程，可是要么数据不公开，要么公开给其余部门的数据存在必定误差，不具有真实性。
为何会这样？由于涉及部门之间的利益和业绩冲突问题。某些产品经理老是但愿尽量地让用户以为本身设计的产品功能齐全，让老板以为本身作了不少事情。可是不多关心作一个功能所带来的成本投入，或者说不是特别关心这一点。并且不少时候他们也并不太理解技术复杂度给产品带来的负面影响。
这里拿一个看上去很简单的功能来分析一下。
需求： 一个论坛帖子总量的统计
附加需求： 实时更新
在不少人看来，这个功能很是容易实现，执行一条select count(*)的query不就能够获得结果了么？是的，确实只须有一个简单的query就能够获得结果。可是，若是咱们采用的不是MyISAM存储引擎，而是InnoDB存储引擎，那么你们能够试想一下，若是存放帖子的表中已经有上千万帖子，执行这条query语句须要多少成本？恐怕再好的硬件设备都很难高效地完成这样一次查询吧。若是访问量再大一点，那还有人以为这是一件简单的事情么？
既然这样查询不行，那是否是该专门为这个功能建一个表？这个表里只有一个字段，一条记录，就是存放这个统计量，每次有了新的帖子，都将这个值增长1，这样每次都只需要查询这个表就能够获得结果了，这个效率确定可以知足要求。确实，查询效率可以知足要求，但是若是系统帖子产生得很快，在高峰时期可能每秒会有几十甚至上百个帖子产生，恐怕这个统计表又要成为你们的噩梦了。要么由于爆发的问题形成统计结果的不许确，要么由于锁资源争用严重形成总体性能大幅度地降低。
其实这个问题的焦点不该该是实现这个功能的技术细节，而是这个功能的附加要求“实时更新”。当一个论坛的帖子数量很大时，到底有多少人会关注这个统计数据是不是实时变化的？有多少人在意这个数据库在短期内的不精确性？我想恐怕不会有人会傻傻地盯着这个统计数字并追究当本身发了一个帖子回头刷新页面时这个统计数字是否加1？即便明明白白地告诉用户这个统计数据每隔必定时间段更新一次，那又怎样？难道会有不少用户就此很不爽么？
只要去掉了这个“实时更新”的附加条件，就能够很是容易实现这个功能了。就像以前所提的的，建立一个统计表，而后经过一个定时任务每隔必定时间就去更新一次统计值。这样既能够解决统计值查询的效率问题，又能保证不影响新发帖的效率，一箭双雕。
实际上，在应用的系统中还有不少相似功能点能够优化。如某些场合的列表页面参与列表的数据量达到必定数量级别后，彻底能够不用准确地显示这个列表共有多少条信息，总共分了多少页，只须要一个大概的估计值或一个时间段以前的统计值。这样就省略了分页程序在分之前实时计算(COUNT)出知足条件的记录数。
其实，在不少应用系统中，实时和准实时，精确与基本准确，在不少地方所带来是性能消耗多是几个性能的差异。在系统性能优化中，应该尽可能分析出哪些能够不实时和不彻底精确，并做出一些相应的调整，这会给你们带来意想不到的巨大性能提高。
无用功能堆积使系统过分复杂，影响总体性能 不少时候，为系统增长某个功能可能并不需要花费太多的成本，而要想将一个已经运行了一段时间的功能从原有系统中撤下来倒是很是困难的。 首先，对于开发部门，可能要从新整理不少的代码，找出与增长该功能所编写的代码可能有交集的其余功能点，删除没有关联的代码，修改有关联的。 其次，对于测试部门，因为功能的变更，必需要回归测试全部相关的功能点是否正常。可能因为界定困难，不得不将回归范围扩展到很大，测试工做量也很大。 最后，对全部参与撤除下线某个功能是相关工做者来讲，此举没法带来任何实质性的收益，而偏偏相反，带来的只多是风险。 因为上面的这几个因素，可能不多会有公司会有很完善的项目（或者功能）下线机制，也不多有公司能作到及时将系统中某些不合适的功能下线。因此，咱们所面对个应用系统可能老是愈来愈复杂，愈来愈庞大，短时间内的复杂也许并没有太大问题，可是随着时间的积累，所面对的系统就会变得臃肿。不只维护困难，性能也会愈来愈差。尤为是有些并不合理的功能，在设计之初或是刚上线的时候因为数据较小，不会带来多少性能损耗。可随着时间的推移，数据库中的数据量愈来愈大，数据检索愈来愈困难，整个系统带来的资源消耗也就愈来愈大。 并且，并且系统复杂度的不断增长，给后续其余功能的开发带来了实现的复杂度，不少原本很简单的功能，可能由于系统的复杂而不得不增长更多的逻辑判断，形成系统应用程序的计算量增长，自己性能就会受到影响。而若是这些逻辑判断还须要与数据库交互，并经过持久化的数据来完成，那所带来的性能损失就更大，对整个系统的性能影响也就更大了。