影响性能的相关因素

(1).商业需求对性能的影响
应用系统中的每一个功能在设计初衷肯定都是出于为用户提供某种服务，或者满足用户的某种需求,但是，并不是每一个功能在最后都能成功，甚至有些功能的退出可能在整个系统中是画蛇添足。不仅没有为用户提高人物体验度，也没有为用户改进多少功能易用性，反而在整个系统中成为一个累赘，带来资源的浪费。

案例1:
需求:一个论坛帖子总量的统计
附加要求:实时更新

案例2:
某些场合的列表页面参与列表的数据量达到一定数量级之后，完全可以不用精准的显示这个列表总共有多少信息，总共分为多少页，而值需要一个大概的估计值或者一个时间段之前的统计值。这样就省略了我们的分页程序需要在分页前实时COUNT出满足条件的记录数

3.无用功能堆积是系统过度复杂影响整体性能:

很多时候，为系统增加某个功能可能并不需要花费太多的成本，而想要将一个已经运行一段时间的功能从原有系统中撤下了却是非常困难的。
首先，对于开发部门，可能要重新整理很多的代码，找出可能存在与增加该功能所编写的代码有交集的其他功能点，删除没有关联的代码，修改有关联的代码；
其次，对于测试部门，由于功能的变动，必须要回归测试所有相关的功能点是否正常。可能由于界 定困难，不得不将回归范围扩展到很大，测试工作量也很大。
最后，所有与撤除下线某个功能相关的工作参与者来说，又无法带来任何实质性的收益，而恰恰相反是，带来的只可能是风险。
由于上面的这几个因素，可能很少有公司能够有很完善的项目（或者功能）下线机制，也很少有公 司能做到及时将系统中某些不合适的功能下线。所以，我们所面对的应用系统可能总是越来越复杂，越 来越庞大，短期内的复杂可能并无太大问题，但是随着时间的积累，我们所面对的系统就会变得极其臃 肿。不仅维护困难，性能也会越来越差。尤其是有些并不合理的功能，在设计之初或者是刚上线的时候由于数据量较小，带来不了多少性能损耗。可随着时间的推移，数据库中的数据量越来越大，数据检索越来越困难，对真个系统带来的资源消耗也就越来越大。
而且，由于系统复杂度的不断增加，给后续其他功能的开发带来实现的复杂度，可能很多本来很简单的功能，因为系统的复杂而不得不增加很多的逻辑判断，造成系统应用程序的计算量不断增加，本身 性能就会受到影响。而如果这些逻辑判断还需要与数据库交互通过持久化的数据来完成的话，所带来的性能损失就更大，对整个系统的性能影响也就更大了。

(2).系统架构及实现对性能的影响:
1.不适合在数据库中存放的数据
①.二进制多媒体数据
将二进制多媒体数据存放在数据库中，一个问题是数据库空间资源耗用非常严重，另一个问题 是这些数据的存储很消耗数据库主机的CPU资源。这种数据主要包括图片，音频、视频和其他一些相关的二进制文件。这些数据的处理本不是数据的优势，如果我们硬要将他们塞入数据库，肯定会造成数据库的处理资源消耗严重。

②.流水队列数据
我们都知道，数据库为了保证事务的安全性（支持事务的存储引擎）以及可恢复性，都是需要 记录所有变更的日志信息的。而流水队列数据的用途就决定了存放这种数据的表中的数据会不断的被INSERT，UPDATE和DELETE，而每一个操作都会生成与之对应的日志信息。在MySQL中，如果是支持事务的存储引擎，这个日志的产生量更是要翻倍。而如果我们通过一些成熟的第三方队列软件来 实现这个Queue数据的处理功能，性能将会成倍的提升

③.超大文本数据
对于5.0.3之前的MySQL版本，VARCHAR类型的数据最长只能存放255个字节，如果需要存储更长的文本数据到一个字段，我们就必须使用TEXT类型（最大可存放64KB）的字段，甚至是更大的LONGTEXT类型（最大4GB）。而TEXT类型数据的处理性能要远比VARCHAR类型数据的处理性能低下很多。从5.0.3版本开始，VARCHAR类型的最大长度被调整到64KB了，但是当实际数据小于255 Bytes的时候，实际存储空间和实际的数据长度一样，可一旦长度超过255Bytes之后，所占用的存 储空间就是实际数据长度的两倍。
所以，超大文本数据存放在数据库中不仅会带来性能低下的问题，还会带来空间占用的浪费问 题。

2.是否合理的利用了应用层Cache机制？
①.系统各种配置及规则数据
由于这些配置信息变动的频率非常低，访问概率又很高，所以非常适合存使用Cache；

②.活跃用户的基本信息数据
虽然我们经常会听到某某网站的用户量达到成百上千万，但是很少有系统的活跃用户量能够都 达到这个数量级。也很少有用户每天没事干去将自己的基本信息改来改去。更为重要的一点是用户的基本信息在应用系统中的访问频率极其频繁。所以用户基本信息的Cache，很容易让整个应用系统的性能出现一个质的提升。

③.准实时的统计信息数据
谓准实时的统计数据，实际上就是基于时间段的统计数据。这种数据不会实时更新，也很少需要增量更新，只有当达到重新Build该统计数据的时候需要做一次全量更新操作。虽然这种数据即使通过数据库来读取效率可能也会比较高，但是执行频率很高之后，同样会消耗不少资 源。既然数据库服务器的资源非常珍贵，我们为什么不能放在应用相关的内存Cache中呢？

④.其他一些访问频繁但变更较少的数据
除了上面这四种数据之外，在我们面对的各种系统环境中肯定还会有各种各样的变更较少但是访问很频繁的数据。只要合适，我们都可以将对他们的访问从数据库移到Cache中。

3.过度依赖数据库SQL语句的功能造成数据库操作效率低下

4.其他不合理架构导致性能低下
①Cache系统的不合理利用导致Cache命中率低下造成数据库访问量的增加，同时也浪费了Cache 系统的硬件资源投入；
②过度依赖面向对象思想，对系统带来不必要的压力.
③对可扩展性的过渡追求，促使系统设计的时候将对象拆得过于离散，造成系统中大量的复杂Join 语句，而MySQLServer在各数据库系统中的主要优势在于处理简单逻辑的查询，这与其锁定的机制也有较大关系；
④对数据库的过渡依赖，将大量更适合存放于文件系统中的数据存入了数据库中，造成数据库资源的浪费，影响到系统的整体性能，如各种日志信息；
⑤过度理想化系统的用户体验，使大量非核心业务消耗过多的资源，如大量不需要实时更新的数据 做了实时统计计算。

(3).设计对系统的性能影响
不合理的表设计可能会增加数据库的压力，从而影响性能.

(4).硬件环境对系统性能的影响
服务器性能的优劣也会影响数据库的性能

(5).Query语句对系统性能的影响
SQL写得好坏直接影响到查询效率.

(6).综合考虑
在整个系统的性能优化中，如果按照百分比来划分上面几个层面的优化带来的性能收益，可以得出大概如下的数据：
需求和架构及业务实现优化：55%
Query 语句的优化：30%
数据库自身的优化：15%
数据库应用系统的优化，实际上是一个需要多方面配合，多方面优化的才能产生根本性改善的事情。简单来说，可以通过下面三句话来简单的概括数据库应用系统的性能优化：商业需求合理化，系统架构最优化，逻辑实现精简化，硬件设施理性化。