msql 中影响性能的因数

影响性能的因素

• 商业需求对性能的影响
• 系统架构及实现对性能影响
• 其他因素
• 综合考虑

商业需求对性能的影响

1.不合理需求
  需求：一个论坛帖子总量的统计
  附加要求：实时更新
  解决方案：
    1，初级阶段：SELECT COUNT(id) ,直接查询总数，效率低，性能差
    2，新建一个表，在这个表中更新这个汇总数据（频率问题）。每次跟新帖子，总量加1
    3，真正的问题在于，实时？创建一个统计表，隔一段时间统计一次并存入；
    4，采用redis，实时返回总数
2.无用功能堆积
    1，无用的列堆积（废弃的功能，页面进行菜单隐藏，对象属性依然保持）；
    2，错误的表设计；
    3，无用的表关联；

系统架构及实现对性能影响

1. 哪些数据不适合放在数据库中（降低查询效率，增加IO次数）
  1，二进制数据(声音，图像，图片，视频等，直接放入磁盘中)；
  2，流水队列数据（读写频率太高，如日志文件，直接写入文件或者redis中，隔时更新到磁盘）；
  3，超大文本；
2. 合理的cache(哪些数据适合放到cache中?)
  1，系统配置信息；
  2，活跃的用户的基本信息(例如游戏中，经常登录游戏账号)；
  3，活跃用户的定制化信息（读远远大于写）；
  4，基于时间段的统计数据；
  5，读>>>写的数据；
3.减少数据库交互次数
  N+1问题（A对象列表中要显示关联对象的属性，用一条sql把A对象查询出来，然后用N条sql把N个A对象关联的属性查询出）的解决：
    1，使用链接（左右连接）查询：优缺点：关联表过多，性能下降，若一个对象关联N个对象，结果集大；
    2，使用1+1查询：先查A对象列表，在查外键id，在代码中组装(最优，避免了冗余数据和链接查询的缺点)；
  合理的冗余数据：
4.过度依赖数据库SQL 语句的功能
  交叉表；
  不必要的表连接；
  复杂的sql查询，例如几十行的sql
5.重复执行相同的SQL
  在一个页面中，有相同内容，但是使用2条SQL去查询；
6.其他常见系统架构和实现问题
  1、Cache 系统的不合理利用导致Cache 命中率低下造成数据库访问量的增加，同时也浪费了
   Cache系统的硬件资源投入；
  2、过度依赖面向对象思想，对系统可扩展性的过渡追求，促使系统设计的时候将
   对象拆得过于离散，造成系统中大量的复杂Join语句，而MySQL Server 在各数据库系统中的
   主要优势在于处理简单逻辑的查询，这与其锁定的机制也有较大关系；
  3、对数据库的过渡依赖，将大量更适合存放于文件系统中的数据存入了数据库中，造成数据库
   资源的浪费，影响到系统的整体性能，如各种日志信息；
  4、过度理想化系统的用户体验，使大量非核心业务消耗过多的资源，
   如大量不需要实时更新的数据做了实时统计计算。

其他因素

1.SQL引起性能问题的原因
 SQL的执行过程；
  1. 客户端发送一条查询给服务器；
  2. 服务器先会检查查询缓存，如果命中了缓存，则立即返回存储在缓存中的结果。否则进入下一阶段；
  3. 服务器端进行SQL解析、预处理，再由优化器根据该SQL所涉及到的数据表的统计信息进行计算，
    生成对应的执行计划；
  4. MySQL根据优化器生成的执行计划，调用存储引擎的API来执行查询；
  5. 将结果返回给客户端。

  SQL执行的最大瓶颈在于磁盘的IO，即数据的读取；不同SQL的写法，会造成不同的执行计划的执行，而不同的执行计划在IO的上面临完全不一样的数量级，从而造成性能的差距；
  所以,我们说,优化SQL,其实就是让查询优化器根据程序猿的计划选择匹配的执行计划,来减少查询中产生的IO;
2.Schema（表结构） 设计对系统的性能影响
 1，冗余数据的处理；
   适当的数据冗余可以提高系统的整体查询性能(在P2P中,在userinfo对象中有realname和idnumber);
  关系数据库的三范式:
   第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库，是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值；
   第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
   第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。 (不允许有冗余数据)
 2，大表拆小表，有大数据的列单独拆成小表；
   1,在一个数据库中,一般不会设计属性过多的表;
   2,在一个数据库中,一般不会有超过500/1000万数据的表(拆表,按照逻辑拆分,按照业务拆分);
   3,有大数据的列单独拆成小表(富文本编辑器,CKeditor);
 3，根据需求的展示设置更合理的表结构；
 4，把常用属性分离成小表；
  1,在P2P项目中,我们把logininfo和userinfo和account表拆成了三张表;
  2,减少查询常用属性需要查询的列;
  3,便于常用属性的集中缓存;
3.硬件环境对性能影响
  1，提高IO指标
    IOPS：每秒可提供的IO 访问次数；
    IO 吞吐量：每秒的IO 总流量；
  2，提高CPU计算能力；
  3，如果是单独的数据库服务器，提高网络能力；
4.数据库系统场景
   两种典型数据库应用场景：
  1，联机事务处理OLTP（on-line transaction processing）：OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
  2，联机分析处理OLAP（On-Line Analytical Processing）：OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果，数据仓库就是一个典型应用场景；

综合考虑

  需求和架构及业务实现优化：55%
  Query 语句的优化：30%
  数据库自身的优化：15%