1. Dotnet9首页
  2. 数据库

一) 在说数据库优化时,我们应该做些什么?

00 优化之前我们应该做什么?

在说给数据库做性能优化时,我们应该做些什么呢?

我们在优化之前一定要了解数据库内部原理吗?

要去不断调整数据库、操作系统的参数呢?

数据库的性能就只是数据库的架构决定的,跟应用、开发关系不大吗?

我们是不是必须遇到了瓶颈要做读写分离、分库分表呢?

NO!

其实,它们可能都是数据库优化的一部分,但既不是开始,也不是目的,更不是全部。

我们首先要搞懂,为什么要做数据库的优化?

从业务角度出发,是为了减少用户响应时间。

从数据库角度看,是为了减少数据库SQL响应时间。

从数据库的服务器角度来说,是为了充分使用数据库服务器物理资源,减少CPU、IO、内存的使用率。

我们在优化之前,一定要给出一个目标。

•响应时间变短,优化前数据库的平均响应时间是500ms,指定优化目标缩减到200ms。•CPU占用率变少,优化前高峰期使用率70%,优化后变成50%。•IO使用率变低,优化前IO WAIT 30%,优化后10%。•SQL执行时间变短,优化前1000条SQL执行为3600s,优化后降到200s。

还有其他诸如硬解析率、软解析率、TPS压测值,也都可以作为一个指标。

至于指标到底怎么定?我们接下来继续说。

01 做数据库优化有流程吗?

我们应该制定一个什么样的流程,来做数据库优化?

或者说,我们做数据库优化时,应该要经过一个什么流程呢?

如图:

一) 在说数据库优化时,我们应该做些什么?
  • 1、我们首先应该了解待优化的问题;【到底出了什么问题?】
  • 2、收集系统信息;【哪里出了问题?】
  • 3、制定优化目标;【得到客户认可,解决什么问题?】
  • 4、分析性能问题;【具体的问题在哪里?什么原因引起的问题?】
  • 5、制定优化方案;【针对分析出的问题怎么去解决?】
  • 6、实施优化方案;【谁来实施?怎么实施?有没有风险?】
  • 7、判断是否达到优化目标;【效果怎么样?如果不行还需要重新分析问题。】
  • 8、编写优化报告。【目标达到,我们要编写优化报告,告诉客户解决了什么问题。】

以上,便是我们数据库优化的一个大体流程。

接下来具体说说怎么做。

02 信息收集与目标制定

首先,我们要了解待优化的问题。

从哪里了解?用户、运维、开发人员等等。

我们一般能了解到什么信息?

用户一般会说应用访问慢、系统卡、打不开等等。

运维人员会说服务器的硬件资源占用率高,如CPU很高、内存不够了等等

开发人员会说接口总是报错,数据库响应时间变得很长,TPS、QPS压不上去。

那么,这些信息都是真实有效的吗?

我们在这里谨记一个守则:凡是“判断”、“分析”类的信息统统屏蔽,凡是“症状”、“表现”类的信息细细保留。

why?

因为别人的“判断”,特别是来自以上三类人群的“判断”,大部分是片面的,很可能会干扰你的思路,甚至会把你带到沟里去,让你对某些问题视而不见,导致做了大半天的无用功。

我们要有一套自己的优化思路。

在了解到当前待优化的问题后,我们紧跟着要干什么?开始优化吗?

当然不是。

而是最基本的,来到第二步,收集系统信息。并且尽可能全面地收集系统信息。

我们可以从业务、数据库、服务器等角度收集系统信息。分类保存,以便后期优化时使用。

然后才是我们前面章节所说的,制定优化目标。

怎么制定优化目标?

首先是分析数据库大概存在的瓶颈,然后是制定明确的优化目标(如业务、数据库、服务器等多种角度)。

最重要的是,优化前一定要跟客户沟通好,让客户确认本次优化的目标,得到认可。

再接着,就是具体地分析性能问题了。

03 问题分析

问题分析这一块可以说的内容太多了,所以单独放了一小节。

首先,我们可以采用自上而下的顺序进行分析。

操作系统(CPU、IO、NETWORK) -> 数据库实例  -> 数据库对象   -> SQL

对操作系统我们采用什么工具呢?我们现在的服务一般都是部署在Linux上的,所以我们一般使用以下这些工具进行检测。

•SAR•HTOP•NMON•TOP•ETHTOOL•……

那对于数据库,我们有什么工具来分析数据库的等待时间瓶颈呢?

•ORACLE:AWR、STATSPACK、内部视图、GRID CONTROL、STA、SAA、ADDM•MYSQL:慢日志、PERCONA TOOLKIT、MEM、内部视图……•SQLSERVER:SQL PROFILE、内部视图……•POSTGERS:pg_stat_statements、SQL trace……•达梦:AWR、内部视图、监控工具、SQL trace……

在使用上面的工具对操作系统、数据库进行信息收集、初步分析后,我们紧接着就要根据找到的瓶颈进行深入分析。

从哪些方面分析?

•操作系统参数是否配置合理?•数据库参数是否合理?•索引设计合理吗?•数据库有没有bug?排除下•捕获主要的问题SQL,对其进行深入分析•硬件资源是不是不足了?•数据库的选型是否恰当?•数据库表设计是不是合理?•是不是业务流程的设计存在问题导致的数据库性能问题?

从实际的优化经验来说,大部分的数据库性能问题都是由问题SQL导致的。而问题SQL的大部分起因都是索引设计不合理,甚至没有索引。

04 制定及实施优化方案

在找到问题原因后,我们怎么去制定并实施优化方案呢?

•数据库架构调优•数据库表结构优化设计•操作系统内核参数优化•数据库参数优化•添加或删除索引•改写SQL语句•调整应用流程•采用数据库高级特性•升级硬件•……

这些都是优化的方案,那我们怎么选择呢?

归根到底,还是要根据我们问题分析的结果去制定。一个完整的优化方案应该包含如下内容:

•1、背景;•2、问题现象;•3、分析过程及结论;•4、优化建议;•5、实施计划及风险。

我们例举一个案例,这个案例是oracle的。

1、背景

运维人员反应系统报表出不出来。

2、问题现象

XX系统经常夜里12点就刷不出来了,要等很长时间。

3、分析过程及结论

从整体ASH报告分析,数据库性能压力一般,但是特定时间的数据库问题比较明显,一般集中在晚上20:00-凌晨1:00左右。

某些SQL执行时间到达1000s以上。这类SQL必须优化。

4、优化建议

1)从AWR报告抓取问题SQL,提交开发修改。2)对log_XXX_detail等类似大表进行修改,调整字段类型,并对表进行分析。

5、实施计划及风险

基本无风险;但需应用配合,无需重启数据库。

在实施方案的时候,我们需要注意什么?

1、数据库实例优化方案应由运维人员及DBA实施;

2、SQL优化方案由开发人员修改应用措施;

3、任何类型的实施在操作前都需要做好计划及回滚方案。

05 编写优化报告

我们在优化完毕了,这个事情就结束了吗?

不!

我们还要对整体优化做出总结。

why?

因为我们要体现出优化的价值,并且为下次优化打好基础。

我们的报告要能明确体现出优化的效果。

优化报告怎么写?一般注意以下几个要素:

•1、数据库优化背景;•2、索引重建优化前后对比;•3、CPU使用率;•4、磁盘基线;•5、锁使用情况;•6、其他未尽之说明。

为什么要写优化报告?

一言以蔽之,这就是你工作中的业绩报告。如果干了活不被人知,不为人晓,那就是个傻把式。

升职加薪跟你有什么关系呢?

接下来举几个简单的优化报告的案例。

实例1:Oracle

某项目因IO资源不足导致数据库性能低下

数据库现象:CPU大量消耗

应用系统现象:大量IO等待、阵列IO不足

操作:购买新阵列、迁移数据库

效果:问题基本缓解

实例2:SQLSERVER

某项目数据库计算时间超过10小时

数据库现象:CPU和IO占用率较低

应用现象:系统基本空闲

操作:重新改写计算逻辑

效果:效率提升10倍以上

实例3:MYSQL

某项目数据库经常中断

数据库现象:主主模式经常出现数据不一致

应用系统现象:无明显特征

操作:调整架构为MHA模式

效果:数据库故障现象充分缓解

06 总结

梳理下本章我们学习的内容:

1、了解优化流程,收集问题信息。

2、优化流程的重点是问题分析这一步,要能通过科学的方法、便捷的工具,敏锐地发现系统瓶颈或者故障点;

3、优化可以从多个角度考虑,思路要开阔;

4、优化有大致的流程,但,是没有固定方法的。

07 后记

以上这一篇内容是数据库优化系列文章一篇,内容基本上是我在前公司的《数据库训练营》学习到的内容。

我觉得我遇到的这位老师说的很有道理。

其实问题并不可怕,怕的是不知道问题在哪?

问题也不难解决,难的是知道解决问题的方向。

仅以此希望跟大家分享。

后续的文章也会以oracle、mysql为主,从理论到实践,从方法到实战,来继续我们的数据库优化之路。

我的小专栏:https://xiaozhuanlan.com/topic/1273960485

原文出处:微信公众号【妖生 姚毛毛的博客】

原文链接:https://mp.weixin.qq.com/s/s0XGcRwzufCbzi_9owzwCA

本文观点不代表Dotnet9立场,转载请联系原作者。

发表评论

登录后才能评论