数据库瓶颈(1,数据库系统发展至今遇到的最大瓶颈是什么)

其实数据库瓶颈的问题并不复杂，但是又很多的朋友都不太了解1,数据库系统发展至今遇到的最大瓶颈是什么，因此呢，今天小编就来为大家分享数据库瓶颈的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

当数据库变慢时的解决方法有哪些

我们使用电脑和手机时候最不能忍受就是设备又卡又慢了,严重影响我们工作或者游戏体验。当数据库变慢时，我们应如何入手，下面的解决方法。

方法步骤

第一章检查系统的状态

1.1使用sar来检查操作系统是否存在IO问题

1.2关注内存vmstat

1.3找到使用资源特别大的Oracle的session及其执行的语句

1.4查找前十条性能差的sql语句

当数据库变慢时，我们应如何入手

当应用管理员通告现在应用很慢、数据库很慢时，当Oracle DBA在数据库上做几个示例的Select也发现同样的问题时，有些时侯就会无从下手，因为DBA认为数据库的各种命种率都是满足Oracle文档的建议。实际上如今的优化己经向优化等待(waits)转型了，实际中性能优化最根本的出现点也都集中在I/O，这是影响性能最主要的方面，由系统中的等待去发现Oracle库中的不足、操作系统某些资源利用的不合理是一个比较好的办法。下面把一些实践经验与大家分享，本文测重于Unix环境。

第一章检查系统的状态

通过操作系统的一些工具检查系统的状态，比如CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲，这也可能不是一个正常的状态，因为cpu可能正等待IO的完成。除此之外，还应观注那些占用系统资源(cpu、内存)的进程。

1.1使用sar来检查操作系统是否存在IO问题

#sar-u 2 10--即每隔2秒检察一次，共执行20次。

结果示例：

注：在redhat下，%system就是所谓的%wio。

Linux 2.4.21-20.ELsmp(YY075) 05/19/2005

10:36:07 AM CPU%user%nice%system%idle

10:36:09 AM all 0.00 0.00 0.13 99.87

10:36:11 AM all 0.00 0.00 0.00 100.00

10:36:13 AM all 0.25 0.00 0.25 99.49

10:36:15 AM all 0.13 0.00 0.13 99.75

10:36:17 AM all 0.00 0.00 0.00 100.00

其中：

Ø%usr指的是用户进程使用的cpu资源的百分比;

Ø%sys指的是系统资源使用cpu资源的百分比;

Ø%wio指的是等待io完成的百分比，这是值得观注的一项;

Ø%idle即空闲的百分比。

如果wio列的值很大，如在35%以上，说明系统的IO存在瓶颈，CPU花费了很大的时间去等待I/O的完成。Idle很小说明系统CPU很忙。像以上的示例，可以看到wio平均值为11，说明I/O没什么特别的问题，而idle值为零，说明cpu已经满负荷运行了。

当系统存在IO问题时，可以从以下几个方面解决：

Ø联系相应的操作系统的技术支持对这方面进行优化，比如hp-ux在划定卷组时的条带化等方面。

Ø查找Oracle中不合理的sql语句，对其进行优化;

Ø对Oracle中访问量频繁的表除合理建索引外，再就是把这些表分表空间存放以免访问上产生热点，再有就是对表合理分区。

1.2关注内存

常用的工具便是vmstat，对于hp-unix来说，可以用glance。Aix来说可以用topas。当发现vmstat中pi列非零，memory中的free列的值很小，glance、topas中内存的利用率多于80%时，这时说明内存方面应该调节一下。方法大体有以下几项：

Ø划给Oracle使用的内存不要超过系统内存的1/2，一般保在系统内存的40%为益。

Ø为系统增加内存;

Ø如果你的连接特别多，可以使用MTS的方式;

Ø打全补丁，防止内存漏洞。

1.3找到使用资源特别大的Oracle的session及其执行的语句

Hp-unix可以用glance或top。IBM AIX可以用topas。此外可以使用ps的命令。

通过这些程序可以找到点用系统资源特别大的这些进程的进程号，就可以通过以下的sql语句发现这个pid正在执行哪个sql，这个sql最好在pl/sql developer、toad等软件中执行：

SELECT a.username, a.machine, a.program, a.sid, a.serial#, a.status,

c.piece, c.sql_text

FROM v$session a, v$process b, v$sqltext c

WHERE b.spid='ORCL'

AND b.addr= a.paddr

AND a.sql_address= c.address(+)

ORDER BY c.piece;

可以把得到的这个sql分析一下，看一下它的执行计划是否走索引。对其优化避免全表扫描，以减少IO等待，从而加快语句的执行速度。

提示：在做优化sql时，经常碰到使用in的语句，这时一定要用exists把它给换掉，因为Oracle在处理In时是按Or的方式做的，即使使用了索引也会很慢。比如：

SELECT col1, col2, col3 FROM table1 a

WHERE a.col1 NOT IN(SELECT col1 FROM table2)

可以换成：

SELECT col1, col2, col3 FROM table1 a

WHERE NOT EXISTS

(SELECT'x' FROM table2 b WHERE a.col1=b.col1)

1.4查找前十条性能差的sql语句

SELECT* FROM(SELECT parsing_user_id, executions, sorts, command_type,

disk_reads, sql_text FROM v$sqlarea

ORDER BY disk_reads DESC)

WHERE ROWNUM<10;

第二章检查会话状态

要快速发现Oracle Server的性能问题的原因，可以求助于v$session_wait视图，看系统的这些session在等什么，使用了多少的IO。以下是参考脚本：

--脚本说明：查看占I/O较大的正在运行的session：

SELECT se.sid, se.serial#, pr.spid, se.username, se.status, se.terminal,

se.program, se.module, se.sql_address, st.event, st.p1text,

si.physical_reads, si.block_changes

FROM v$session se, v$session_wait st, v$sess_io si, v$process pr

WHERE st.sid=se.sid AND st.sid=si.sid

AND se.PADDR=pr.ADDR

AND se.sid>6

AND st.wait_time=0

AND st.event NOT LIKE'%SQL%'

ORDER BY physical_reads DESC;

对检索出的结果的几点说明：

1.以上是按每个正在等待的session已经发生的物理读排的序，因为它与实际的I/O相关。

2.可以看一下这些等待的进程都在忙什么，语句是否合理?

SELECT sql_address FROM v$session WHERE sid=;

SELECT* FROM v$sqltext WHERE address=;

执行以上两个语句便可以得到这个session的语句。

也以用alter system kill session'sid, serial#';把这个session杀掉。

3.应观注一下event列，这是调优的关键一列，下面对常出现的event做以简要的说明：

1) buffer busy waits，free buffer waits这两个参数所标识是dbwr是否够用的问题，与IO很大相关的，当v$session_wait中的free buffer wait的条目很小或没有时，说明系统的dbwr进程决对够用，不用调整;free buffer wait的条目很多，系统感觉起来一定很慢，这时说明dbwr已经不够用了，它产生的wio已经成为数据库性能的瓶颈，这时的解决办法如下：

Ø增加写进程，同时要调整db_block_lru_latches参数：

示例：修改或添加如下两个参数

db_writer_processes=4

db_block_lru_latches=8

Ø开异步IO。IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。

2) db file sequential read，指的是顺序读，即全表扫描，这也是应尽量减少的部分，解决方法就是使用索引、sql调优，同时可以增大db_file_multiblock_read_count这个参数。

3) db file scattered read参数指的是通过索引来读取，同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。

4) latch free与栓相关，需要专门调节。

5)其他参数可以不特别观注

补充：解决系统变慢的常用技巧方法

1、在我的电脑窗口，右击要清理的盘符―“属性”―“清理磁盘”--勾选要删除的文件--确定--是。

2、右键浏览器e――属性――点2个删除1个清除(都要逐一确定)――确定。

3、把C:\WINDOWS\Prefetch(预读文件)把里面的文件全部删除

4、用优化大师或超级兔子清理注册表和垃圾文件。

5、“开始”――运行中输入msconfig――确定――启动――除了输入法ctfmon以外的勾全去掉。

6、右键我的电脑”――属性――点高级――点启动和故障恢复中的设置――去掉所有的勾――写入调试信息选择“无”――确定――点高级下面错误报告――点禁用――2次确定。

7、“开始”..打开控制面板中的文件夹选项..点查看..点去末项自动搜索文件夹前面的勾..确定。

8、右键我的电脑――属性――硬件――设备管理器――双击IDE控制器――次要通道――高级设置――传送模式都选DMA――设备类型选无――确定――主要通道也同样设置――确定。

9、右键C盘进行磁盘清理和其它选项中的系统还原清理。

有哪些手段可以查看mysql数据库性能瓶颈

通过sysbench的oltp_read_write测试来模拟业务压力、以此来给指定的硬件环境配置一份比较合理的MySQL配置文件。

环境介绍

硬件配置

请点击输入图片描述

软件环境

请点击输入图片描述

优化层级与指导思想

优化层级

MySQL数据库优化可以在多个不同的层级进行，常见的有：

SQL优化

参数优化

架构优化

本文重点关注：参数优化

指导思想

日志先行--一个事务能否成功提交的关键是日志是否成功落盘，与数据没有太大的关系；也就是说对写的优化可以表述为各方面的资源向写操作倾斜。

瓶颈分析--通过show global status的各个计数器的值基本上就能分析出当前瓶颈所在，再结合一些简单的系统层面的监控工具如top iostat就能明确瓶颈。

整体性能是“读”&“写”之间的再平衡。

1,数据库系统发展至今遇到的最大瓶颈是什么

以国产数据库的发展来看，瓶颈主要集中在两个方面，一是研发，二是生态。

在研发方面，数据库研发技术起点高，难度大，一个成熟的数据库产品要具备深厚的技术积累和沉淀才能逐渐走向市场。国内很多厂商为求速成，要么基于一个现有的开源系统改进，要么从其他厂商购买源码授权，虽然起步比较快，但是产品架构几乎不可能调整，短期内也不可能掌握其核心技术，因此遇到客户新需求这样的问题时难以快速响应。

由此可见，要想实现数据库技术突破，只有靠自主研发，在实际应用场景中不断发现问题，从而革新技术，实现突破。国产数据库发展的几十年间，从“可用”、“试着用”到“好用”、“喜欢用”的方向不断发展，产品的架构、性能、功能、安全等方面都有了很大进步，国人在对待国产基础软件的态度上也有所转变。国产数据库要想快速发展，也需要在国家核高基等政策的推动下，在建立中国自主产权的软件国产化的重大主题的呼唤下，让国产数据库在一系列的项目中不断磨合，促进其产品的优化和成熟，使其更能适应市场，满足用户需求。

在生态方面，国产数据库生态建设困难，打破以国外品牌为主导的生态圈尤其困难。当前国外知名数据库在业内处于绝对领先地位，短期内无法撼动国际巨头的地位。如今，国内数据库厂商多达几十家，局面还有些混乱，单凭任何一家企业的力量难以打破国外市场的垄断，需要有“国家队”出现，集中投入财力物力，形成几家大型的国产数据库企业，深化数据库的市场化程度，集中力量牵头建设生态圈，共同推进我国的信息化建设。

性能测试如何确定数据库是否是瓶颈

具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。

为什么当磁盘IO成瓶颈之后,数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？

相信大部分做数据库运维的朋友，都遇到这种情况。数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert操作，需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？

dba此时心中有无限的疑惑，到底是什么原因呢?磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？还是数据库内部出问题？昨天不是还好好的吗？

当数据库出现响应时间不稳定的时候，我们在操作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO.数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概性能就雪崩了。为什么操作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？

如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。

在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。

咱们先来提问题。buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。

提问.数据页不在buffer bool里面该怎么办？

回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool,图片中显示

buffer_read_page函数栈的顶层是pread64(),调用了操作系统的读函数。

buf_read_page的代码

如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的操作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer中，无法直接使用该数据页，必须等待操作系统完成IO.

再接着上面的回答提问：

当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。

试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool,这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。

通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。

再继续扩展问题：如果会话线程A经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。

由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。

再回头来看上面的问题，mysql数据库出现性能下降时，可以看到操作系统有读IO。原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写操作是不堵塞执行sql的会话线程的。所以，即使看到操作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size,基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在操作系统上基本看不到读的IO。当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool,则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。

关于本次数据库瓶颈和1,数据库系统发展至今遇到的最大瓶颈是什么的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。