数据库性能分析 影响数据库性能的主要因素有哪些

其实数据库性能分析的问题并不复杂，但是又很多的朋友都不太了解影响数据库性能的主要因素有哪些，因此呢，今天小编就来为大家分享数据库性能分析的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

影响数据库性能的主要因素有哪些

以MySQL为例：

1、sql查询速度

2、网卡流量

3、服务器硬件

4、磁盘IO

以上因素并不是时时刻刻都会影响数据库性能，而就像木桶效应一样。如果其中一个因素严重影响性能，那么整个数据库性能就会严重受阻。另外，这些影响因素都是相对的。

例如：当数据量并没有达到百万千万这样的级别，那么sql查询速度也许就不是个重要因素，换句话说，你的sql语句效率适当低下可能并不影响整个效率多少，反之，这种情况，无论如何怎么优化sql语句，可能都没有太明显的效果。

1、SQL查询速度

风险：效率低下的SQL

2、网卡流量

风险：网卡IO被占满（100Mb/8=100MB）

方案：

①减少从服务器的数量。从服务器都要从主服务器上复制日志，所以，从服务器越多，网络流量越大。

②进行分级缓存。前方大量缓存突然失效会对数据库造成严重的冲击。

③避免使用“select*”进行查询

④分离业务网络和服务器网络

3、磁盘IO

风险：磁盘IO性能突然下降。

方案：使用更好的磁盘设备解决。

如何查看mysql数据库的性能

如何提高MySQL Limit查询的性能?

在MySQL数据库操作中，我们在做一些查询的时候总希望能避免数据库引擎做全表扫描，因为全表扫描时间长，而且其中大部分扫描对客户端而言是没有意义的。其实我们可以使用Limit关键字来避免全表扫描的情况，从而提高效率。

有个几千万条记录的表 on MySQL 5.0.x，现在要读出其中几十万万条左右的记录。常用方法，依次循环：

select* from mytable where index_col= xxx limit offset, limit;

经验：如果没有blob/text字段，单行记录比较小，可以把 limit设大点，会加快速度。

问题：头几万条读取很快，但是速度呈线性下降，同时 mysql server cpu 99%，速度不可接受。

调用 explain select* from mytable where index_col= xxx limit offset, limit;

显示 type= ALL

在 MySQL optimization的文档写到"All"的解释

A full table scan is done for each combination of rows from the previous tables. This is normally not good if the table is the first table not marked const, and usually very bad in all other cases. Normally, you can avoid ALL by adding indexes that allow row retrieval from the table based on constant values or column values from earlier tables.

看样子对于 all, mysql就使用比较笨的方法，那就改用 range方式？因为 id是递增的，也很好修改 sql。

select* from mytable where id> offset and id< offset+ limit and index_col= xxx

explain显示 type= range，结果速度非常理想，返回结果快了几十倍。

Limit语法：

SELECT* FROM table LIMIT [offset,] rows| rows OFFSET offset

LIMIT子句可以被用于强制 SELECT语句返回指定的记录数。LIMIT接受一个或两个数字参数。参数必须是一个整数常量。

如果给定两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数目。初始记录行的偏移量是 0(而不是 1)。

为了与 PostgreSQL兼容，MySQL也支持句法：LIMIT# OFFSET#。

mysql> SELECT* FROM table LIMIT 5,10;//检索记录行6-15

//为了检索从某一个偏移量到记录集的结束所有的记录行，可以指定第二个参数为-1

mysql> SELECT* FROM table LIMIT 95,-1;//检索记录行96-last

//如果只给定一个参数，它表示返回最大的记录行数目，换句话说，LIMIT n等价于 LIMIT 0,n

mysql> SELECT* FROM table LIMIT 5;//检索前5个记录行

MySQL的limit给分页带来了极大的方便，但数据量一大的时候，limit的性能就急剧下降。同样是取10条数据，下面两句就不是一个数量级别的。

select* from table limit 10000,10

select* from table limit 0,10

文中不是直接使用limit，而是首先获取到offset的id然后直接使用limit size来获取数据。根据他的数据，明显要好于直接使用limit。

这里我具体使用数据分两种情况进行测试。

1、offset比较小的时候：

select* from table limit 10,10

//多次运行，时间保持在0.0004-0.0005之间

Select* From table Where vid＞=(Select vid From table Order By vid limit 10,1) limit 10

//多次运行，时间保持在0.0005-0.0006之间，主要是0.0006

结论：偏移offset较小的时候，直接使用limit较优。这个显然是子查询的原因。

2、offset大的时候：

select* from table limit 10000,10

//多次运行，时间保持在0.0187左右

Select* From table Where vid＞=(Select vid From table Order By vid limit 10000,1) limit 10

//多次运行，时间保持在0.0061左右，只有前者的1/3。可以预计offset越大，后者越优。

怎样对Access数据库进行性能分析

1

首先打开Access数据库，单击“数据库工具”菜单中的“分析性能”项，弹出“性能分析器”窗口。

2

在弹出的“性能分析器”窗口中，默认为“表”选择框。通常选择对全部表进行性能分析，点击“全选”，所有表前面的复选框被勾选中，点“确定”开始分析。

3

如果分析后，弹出提示框显示“性能分析没有改进所选对象的建议”，说明没有必要对当前数据库性能进行优化，无须进行后续步骤；

否则，会弹出分析结果窗口：列表中每一项前面都有一个符号，每个符号都代表一个含义，在这个对话框中都有介绍。如果在列表框中有“推荐”和“建议”，我们

就点击“全选”按钮，这时在列表框中的全部项都被选中。然后点击“优化”按钮，等一会儿，会发现原来的“推荐”和“建议”项都变成了“更正”项，说明已经

将这些问题都解决了。带“灯泡”符号的“意见”项没有变化，当选中其中一个“意见”选项时，在“分析注释”中详细列出Access为解决这个问题所出的意

见。

4

另外，“数据库工具”菜单中的“数据库文档管理器”选项，可以打印出所建数据库各对象的全部信息。点击“数据库文档管理器“，在弹出的对话框中点击"全

选"，所有表前面的复选框被勾选中。在这个对话框上有一个“选项”按钮，这个按钮是用来确定打印表的定义，让我们单击该按钮，会弹出一个对话框。

5

在这个对话框中包含“表含义”、“字段包含”、“索引包含”这三个含义组，选择组中不同的选项，会改变打印表显示的信息内容。当我们完成这些工作，单击“确定”按钮。

6

在弹出的打印表中，列出了数据库表各类属性信息，有经验的Access使用者就可以根据这些信息资料分析出所建立的数据库有哪些问题了。

SQLServer和Oracle数据库分析(oraclesql性能分析)

分析原则：

1、具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

2、查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。分段排除法很有效。

分析的信息来源：1、根据场景运行过程中的错误提示信息；

2、根据测试结果收集到的监控指标数据。

一、错误提示分析

分析实例：

1、Error:“10.10.10.30:8080〃:[10060]Connection

Error::Server“10.10.10.30〃

分析：

A、应用服务死掉（小用户时：程序上的问题。程序上处理数据库的问题）

B、应用服务没有死（应用服务参数设置问题）

例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AeptBacklog属性值设得过低。如果连接时收到消息，说明应提高该值，每次增加25%

C、数据库的连接（1、在应用服务的性能参数可能太小了；2、数据库启动的最大连接数（跟硬件的内存有关）。）

分析：可能是以下原因造成

A、应用服务参数设置太大导致服务器的瓶颈；B、页面中图片太多；C、在程序处理表的时候检查字段太大多。

二．监控指标数据分析

1、最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么可行。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2、业务操作响应时间：

分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。细分事务并分析每个页面组件的性能。如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3、服务器资源监控指标：内存：

1、UNIX资源监控中指标内存页交换速率（Pagingrate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2、Windows资源监控中，如果Process计数器和ProcessWorkingSet计数器的值在长时间内持续升高，同时Memory计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆：很高的换页率()；进程进入不活动状态；交换区所有磁盘的活动次数可高；可高的全局系统CPU利用率；内存不够出错()。

处理器：

1、UNIX资源监控（Windows操作系统同理）中指标CPU占用率（），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQLServer，可接受的最大上限是80-85%合理使用的范围在60%至70%。

2、Windows资源监控中，如果System大于2，而处理器利用率（）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆：很慢的响应时间()；CPU空闲时间为零()；过高的用户占用CPU时间()；过高的系统占用CPU时间()；长时间的有很长的运行进程队列()。

磁盘I/O：

1、UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Diskrate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

2、Windows资源监控中，如果DiskTime和Avg.DiskQueueLength的值很高，而PageReads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆：过高的磁盘利用率(highdiskutilization)；

太长的磁盘等待队列(largediskqueuelength)；

等待磁盘I/O的时间所占的百分率太高(largepercentageoftimewaitingfordiskI/O)；

太高的物理I/O速率：largephysicalI/Orate(notsufficientinitself)；

过低的缓存命中率(lowbuffercachehitratio(notsufficientinitself))；

太长的运行进程队列，但CPU却空闲(largerunqueuewithidleCPU)。

4、数据库服务器：

SQLServer数据库：

1、SQLServer资源监控中指标缓存点击率（CacheHitRatio），该值越高越好。如果持续低于80%，应考虑增加内存。

2、如果FullScans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。

3、NumberofDeadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

4、LockRequests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：

1、如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率：select(sum(pins-reloads))/sum(pins)fromv$librarycache；

select(sum(gets-getmisses))/sum(gets)fromv$rowcache；

自由内存：select*fromv$sgastatwherename=‘freememory’。

2、如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：selectname,valuefromv$sysstatwherenamein(‘dbblockgets’，‘consistentgets’‘physicalreads’)HitRatio=1-(physicalreads/(dbblockgetsconsistentgets))。

3、如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况：selectname，valuefromv$sysstatwherename=‘redologspacerequests’。

4、如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。

内存排序命中率：selectround((100*b.value)/decode((a.valueb.value)，0，1，(a.valueb.value)),2)fromv$sysstata，v$sysstatbwherea.name=’sorts(disk)’andb.name=’sorts(memory)’

注：上述SQLServer和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

好了，文章到此结束，希望可以帮助到大家。