一、影响性能的因素
1.1 商业需求影响性能
1.1.1 不合理需求
需求:一个论坛帖子总量的统计
附加要求:实时更新
- 初级阶段:SELECT COUNT(*)
- 新建一个表,在这个表中更新这个汇总数据(频率问题)
- 真正的问题在于,实时?
- 创建一个统计表,隔一段时间统计一次并存入;
1.1.2 无用功能堆积
- 无用的列堆积;
- 错误的表设计;
- 无用的表关联;
1.2 系统架构及实现对性能影响
1.2.1 哪些数据不适合放在数据库中
- 二进制数据;
- 流水队列数据;
- 超大文本;
1.2.2 合理的 Cache
哪些数据适合放到cache中?
1,系统配置信息;
2,活跃的用户的基本信息;
3,活跃用户的定制化信息;
4,基于时间段的统计数据;
5,读>>>写的数据;
1.2.3 减少数据库交互次数
N+1问题的解决:
- 使用链接查询;
- 使用1+1查询;
1.2.4 过度依赖数据库SQL 语句的功能
- 交叉表;
- 不必要的表连接;
1.2.5 重复执行相同的SQL
- 在一个页面中,有相同内容,但是使用2条SQL去查询;
1.3 其他常见系统架构和实现问题
- Cache 系统的不合理利用导致Cache 命中率低下造成数据库访问量的增加,同时也浪费了Cache系统的硬件资源投入;
- 过度依赖面向对象思想,对系统可扩展性的过渡追求,促使系统设计的时候将对象拆得过于离散,造成系统中大量的复杂Join语句,而MySQL Server 在各数据库系统中的主要优势在于处理简单逻辑的查询,这与其锁定的机制也有较大关系;
- 对数据库的过渡依赖,将大量更适合存放于文件系统中的数据存入了数据库中,造成数据库资源的浪费,影响到系统的整体性能,如各种日志信息;
- 过度理想化系统的用户体验,使大量非核心业务消耗过多的资源,如大量不需要实时更新的数据做了实时统计计算。
1.4 其他因素
1.4.1 SQL引起性能问题的原因
SQL的执行过程;
- 客户端发送一条查询给服务器
- 服务器先会检查查询缓存,如果命中了缓存,则立即返回存储在缓存中的结果。否则进入下一阶段;
- 服务器端进行SQL解析、预处理,再由优化器根据该SQL所涉及到的数据表的统计信息进行计算,生成对应的执行计划;
- MySQL根据优化器生成的执行计划,调用存储引擎的API来执行查询;
- 将结果返回给客户端。
磁盘IO
- SQL执行的最大瓶颈在于磁盘的IO,即数据的读取;不同SQL的写法,会造成不同的执行计划的执行,而不同的执行计划在IO的上面临完全不一样的数量级,从而造成性能的差距;
1.4.2 Schema 设计对系统的性能影响
- 冗余数据的处理;
- 大表拆小表,有大数据的列单独拆成小表;
- 根据需求的展示设置更合理的表结构;
- 把常用属性分离成小表;
1.4.3 硬件环境对性能影响
- 提高IO指标
- IOPS:每秒可提供的IO 访问次数;
- IO 吞吐量:每秒的IO 总流量;
- 提高CPU计算能力;
- 如果是单独的数据库服务器,提高网络能力;
1.4.4 数据库系统场景
两种典型数据库应用场景:
1,联机事务处理OLTP(on-line transaction processing):OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。
2,联机分析处理OLAP(On-Line Analytical Processing):OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果,数据仓库就是一个典型应用场景;
OLTP
OLTP的数据库应用特点:
1,系统总体数据量较大,但活动数据量较小;
2,IO访问频繁,单涉及数据量较小,分布离散;
3,并发很高;
4,网络交互数据量较小,但交互频繁;
OLTP系统硬件架构选型:
1,大量的合理的cache设计,能够大大减少数据库的交互;应尽量的扩大内存容量;
2,IOPS指标要求较高;
3,CPU的计算能力,并行计算能力要求较高;
4,对外网络要求较高;
OLAP
特点:
1,数据量非常大,数据访问集中,数据活跃度分布平均;
2,并发访问较低,
3,每次检索的数量非常多;
架构选型:
1,硬盘存储容量需要非常大;
2,对存储设备的IO吞吐量要求很高;
3,CPU要求较低;
4,对外网络要求不高;
1.5 综合考虑
- 需求和架构及业务实现优化:55%
- Query 语句的优化:30%
- 数据库自身的优化:15%
二、 SQL优化
2.1 SQL优化原则
2.1.1 选择需要优化的SQL
- 优先优化高并发低消耗的SQL;

最低0.47元/天 解锁文章
1587

被折叠的 条评论
为什么被折叠?



