msql 中影响性能的因数

﹏ヽ暗。殇╰゛Y 2022-01-21 08:39 235阅读 0赞

**影响性能的因素**

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

> **商业需求对性能的影响**

**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. 将结果返回给客户端。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM4MDY4ODEy_size_16_color_FFFFFF_t_70]  
  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%

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM4MDY4ODEy_size_16_color_FFFFFF_t_70]: /images/20220121/59ba7fc804ae40599d22428133d8cc9c.png