数据库性能

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

以Mysql为例：

影响数据库性能的主要因素总结如下：

1、sql查询速度

2、网卡流量

3、服务器硬件

4、磁盘IO

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

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

相关内容拓展：

1、SQL查询速度

风险：效率低下的SQL

2、网卡流量

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

方案：

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

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

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

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

3、磁盘IO

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

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

② 哪些因素影响了数据库性能

网络宽带，磁盘IO，查询速度都会影响到数据库的性能。

具体问题具体分析，举例来说明为什么磁盘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_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，数据库的性能会非常差。

③ 如何进行数据库性能分析

使用RichAPM可以直接针对不同类型的数据库性能进行分析，包括MySQL、Oracle、SQL Server三类关系型数据库及Memcache、redis两类非关系型数据库。

④ 数据库 性能问题

在没有给id建索引的情况下：
2者都是全表扫描；扫描1万行数据当然比100万行快得多
Where这个关键字没什么原理
就是告诉分析器，下面是条件而已
优化（指建索引）跟Where的条件息息相关

⑤ 如何优化数据库的性能

--数据库性能调优
--1.聚集索引、主键
--2.尽量不要用临时表
--3.多多使用事务
--4.表设计要规范
--5.不要使用游标
--6.避免死锁
--7.不要打开大数据集
--8.最好不要select *
--9.不要使用text数据类型，用varchar
--10.不要给诸如“性别”列创建索引
--11.不要使用Insert插入大量的数据
--12.尽量用join代替where,因为where进行全表搜索

⑥ 优化数据库性能的方式有哪些

优化SQL语句
写存储过程
给表建索引
减少一些不必要的查询
比如：只要查询demo表中的
name
字段一般都会这样写
"select
*
from
demo"
这样写他是查询的整张表如果有很多的字段这样差出来的效率是很低的
可以写成这样
"select
name
from
deom"

⑦ 衡量数据库性能的重要指标

具体来说，本文包括以下内容:

• 事务

• 查询性能

• 用户和查询冲突

• 容量

• 配置

• NoSQL 数据库

事务

事务可以观察真实用户的行为：能够在应用交互时捕获实时性能。众所周知，测量事务的性能包括获取整个事务的响应时间和组成事务的各个部分的响应时间。通常我们可以用这些响应时间与满足事务需求的基线对比，来确定当前事务是否处于正常状态。

如果你只想衡量应用的某个方面，那么可以评估事务的行为。所以，尽管容器指标能够提供更丰富的信息，并且帮助你决定何时对当前环境进行自动测量，但你的事务就足以确定应用性能。无需向应用程序服务器获取 CPU 的使用情况，你更应该关心用户是否完成了事务，以及该事务是否得到了优化。

补充一个小知识点，事务是由入口点决定的，通过该入口点可以启动事务与应用进行交互。

一旦定义了事务，会在整个应用生态系统中对其性能进行测量，并将每个事务与基线进行比对。例如，我们可能会决定当事务的响应时间与基线相比，一旦慢于平均响应时间的两个标准差是否就应该判定为异常，如图1所示。



• 图1-基于基线评估当前事务响应时间

用于评估事务的基线与正在进行的事务活动在时间上是一致的，但事务会由每个事务执行来完善。例如，当你选定一个基线，在当前事务结束之后，将事务与平均响应时间按每天的小时数和每周的天数进行对比，所有在那段时间内执行的事务都将会被纳入下周的基线中。通过这种机制，应用程序可以随时间而变化，而无需每次都重建原始基线；你可以将其看作是一个随时间移动的窗口。

总之，事务最能反映用户体验的测量方法，所以也是衡量性能状况最重要的指标。

查询性能
最容易检测到查询性能是否正常的指标就是查询本身。由查询引起的问题可能会导致时间太长而无法识别所需数据或返回数据。所以不妨在查询中排查以下问题。

1. 选择过多冗余数据

编写查询语句来返回适当的数据是远远不够的，很可能你的查询语句会返回太多列，从而导致选择行和检索数据变得异常缓慢。所以，最好是列出所需的列，而不是直接用 SELECT*。当需要在特定字段中查询时，该计划可能会确定一个覆盖索引从而加快结果返回。覆盖索引通常会包含查询中使用的所有字段。这意味着数据库可以仅从索引中产生结果，而不需要通过底层表来构建。

另外，列出结果中所需的列不仅可以减少传输的数据，还能进一步提高性能。

2. 表之间的低效联接

联接会导致数据库将多组数据带到内存中进行比较，这会产生多个数据库读取和大量 CPU。根据表的索引，联接还可能需要扫描两个表的所有行。如果写不好两个大型表之间的联接，就需要对每个表进行完整扫描，这样的计算量将会非常大。其他会拖慢联接的因素包括联接列之间存在不同的数据类型、需要转换或加入包含 LIKE 的条件，这样就会阻止使用索引。另外，还需注意避免使用全外联接；在恰当的时候使用内部联接只返回所需数据。

3. 索引过多或过少

如果查询优化没有可用的索引时，数据库会重新扫描表来产生查询结果，这个过程会生成大量的磁盘输入/输出（I/O）。适当的索引可以减少排序结果的需要。虽然非唯一值的索引在生成结果时，不能像唯一索引那样方便。如果键越大，索引也会变大，并通过它们创建更多的磁盘 I/O。大多数索引是为了提高数据检索的性能，但也需要明白索引本身也会影响数据的插入和更新，因为所有相关联的指标都必须更新。

4. 太多的SQL导致争用解析资源

任何 SQL 查询在执行之前都必须被解析，在生成执行计划之前需要对语法和权限进行检查。由于解析非常耗时，数据库会保存已解析的 SQL 来重复利用，从而减少解析的耗时。因为 WHERE 语句不同，所以使用文本值的查询语句不能被共享。这将导致每个查询都会被解析并添加到共享池中，由于池的空间有限，一些已保存的查询会被舍弃。当这些查询再次出现时，则需要重新解析。

用户和查询冲突
数据库支持多用户，但多用户活动也可能造成冲突。

1. 由慢查询导致的页/行锁定

为了确保查询产生精确的结果，数据库必须锁定表以防止在运行读取查询时再发生其他的插入和更新行为。如果报告或查询相当缓慢，需要修改值的用户可能需要等待至更新完成。锁提示能帮助数据库使用最小破坏性的锁。从事务数据库中分离报表也是一种可靠的解决方法。

2. 事务锁和死锁

当两个事务被阻塞时会出现死锁，因为每一个都需要使用被另一个占用的资源。当出现一个普通锁时，事务会被阻塞直到资源被释放。但却没有解决死锁的方案。数据库会监控死锁并选择终止其中一个事务，释放资源并允许该事务继续进行，而另一个事务则回滚。

3. 批处理操作造成资源争夺

批处理过程通常会执行批量操作，如大量的数据加载或生成复杂的分析报告。这些操作是资源密集型的，但可能影响在线用户的访问应用的性能。针对此问题最好的解决办法是确保批处理在系统使用率较低时运行，比如晚上，或用单独的数据库进行事务处理和分析报告。

容量
并不是所有的数据库性能问题都是数据库问题。有些问题也是硬件不合适造成的。

1. CPU 不足或 CPU 速度太慢

更多 CPU 可以分担服务器负载，进一步提高性能。数据库的性能不仅是数据库的原因，还受到服务器上运行其他进程的影响。因此，对数据库负载及使用进行审查也是必不可少的。由于 CPU 的利用率时时在变，在低使用率、平均使用率和峰值使用率的时间段分别检查该指标可以更好地评估增加额外的 CPU 资源是否有益。

2. IOPS 不足的慢磁盘

磁盘性能通常以每秒输入/输出操作（IOPS）来计。结合 I/O 大小，该指标可以衡量每秒的磁盘吞吐量是多少兆。同时，吞吐量也受磁盘的延迟影响，比如需要多久才能完成请求，这些指标主要是针对磁盘存储技术而言。传统的硬盘驱动器（HDD）有一个旋转磁盘，通常比固态硬盘（SSD）或闪存更慢。直到近期，SSD 虽然仍比 HDD 贵，但成本已经降了下来，所以在市场上也更具竞争力。

3. 全部或错误配置的磁盘

众所周知，数据库会被大量磁盘访问，所以不正确配置的磁盘可能带来严重的性能缺陷。磁盘应该适当分区，将系统数据目录和用户数据日志分开。高度活跃的表应该区分以避免争用，通过在不同磁盘上存放数据库和索引增加并行放置，但不要将操作系统和数据库交换空间放置在同一磁盘上。

4. 内存不足

有限或不恰当的物理内存分配会影响数据库性能。通常我们认为可用的内存更多，性能就越好。监控分页和交换,在多个非繁忙磁盘中建立多页面空间，进一步确保分页空间分配足够满足数据库要求；每个数据库供应商也可以在这个问题上提供指导。

5. 网速慢

网络速度会影响到如何快速检索数据并返回给终端用户或调用过程。使用宽带连接到远程数据库。在某些情况下，选择 TCP/IP 协议而不是命名管道可显着提高数据库性能。

配置

每个数据库都需设置大量的配置项。通常情况下，默认值可能不足以满足数据库所需的性能。所以，检查所有的参数设置，包括以下问题。

1. 缓冲区缓存太小

通过将数据存储在内核内存，缓冲区缓存可以进一步提高性能同时减少磁盘 I/O。当缓存太小时，缓存中的数据会更频繁地刷新。如果它再次被请求，就必须从磁盘重读。除了磁盘读取缓慢之外，还给 I/O 设备增添了负担从而成为瓶颈。除了给缓冲区缓存分配足够的空间，调优 SQL 查询可以帮助其更有效地利用缓冲区缓存。

2. 没有查询缓存

查询缓存会存储数据库查询和结果集。当执行相同的查询时，数据会在缓存中被迅速检索，而不需要再次执行查询。数据会更新失效结果，所以查询缓存是唯一有效的静态数据。但在某些情况下，查询缓存却可能成为性能瓶颈。比如当锁定为更新时，巨大的缓存可能导致争用冲突。

3. 磁盘上临时表创建导致的 I/O 争用

在执行特定的查询操作时，数据库需要创建临时表，如执行一个 GROUP BY 子句。如果可能，在内存中创建临时表。但是，在某些情况下，在内存中创建临时表并不可行，比如当数据包含 BLOB 或 TEXT 对象时。在这些情况下，会在磁盘上创建临时表。大量的磁盘 I / O 都需要创建临时表、填充记录、从表中选择所需数据并在查询完成后舍弃。为了避免影响性能，临时数据库应该从主数据库中分离出来。重写查询还可以通过创建派生表来减少对临时表的需求。使用派生表直接从另一个 SELECT 语句的结果中选择，允许将数据加到内存中而不是当前磁盘上。

NoSQL 数据库

NoSQL 的优势在于它处理大数据的能力非常迅速。但是在实际使用中，也应该综合参考 NoSQL 的缺点，从而决定是否适合你的用例场景。这就是为什么NoSQL通常被理解为 “不仅仅是 SQL”，说明了 NoSQL 并不总是正确的解决方案，也没必要完全取代 SQL，以下分别列举出五大主要原因。

1. 挑剔事务

难以保持 NoSQL 条目的一致性。当访问结构化数据时，它并不能完全确保同一时间对不同表的更改都生效。如果某个过程发生崩溃，表可能会不一致。一致事务的典型代表是复式记账法。相应的信贷必须平衡每个借方，反之亦然。如果双方数据不一致则不能输入。NoSQL 则可能无法保证“收支平衡”。

2. 复杂数据库

NoSQL 的支持者往往以高效代码、简单性和 NoSQL 的速度为傲。当数据库任务很简单时，所有这些因素都是优势。但当数据库变得复杂，NoSQL 会开始分解。此时，SQL 则比 NoSQL 更好地处理复杂需求，因为 SQL 已经成熟，有符合行业标准的接口。而每个 NoSQL 设置都有一个唯一的接口。

3. 一致联接

当执行 SQL 的联接时，由于系统必须从不同的表中提取数据进行键对齐，所以有一个巨大的开销。而 NoSQL 似乎是一个空想，因为缺乏联接功能。所有的数据都在同一个表的一个地方。当检索数据时，它会同时提取所有的键值对。问题在于这会创建同一数据的多个副本。这些副本也必须更新，而这种情况下，NoSQL 没有功能来确保更新。

4. Schema设计的灵活性

由于 NoSQL 不需要 schema，所以在某些情况下也是独一无二的。在以前的数据库模型中，程序员必须考虑所有需要的列能够扩展，能够适应每行的数据条目。在 NoSQL 下，条目可以有多种字符串或者完全没有。这种灵活性允许程序员迅速增加数据。但是，也可能存在问题，比如当有多个团体在同一项目上工作时，或者新的开发团队接手一个项目时。开发人员能够自由地修改数据库，也可能会不断实现各种各样的密钥对。

5. 资源密集型

NoSQL 数据库通常比关系数据库更加资源密集。他们需要更多的 CPU 储备和 RAM 分配。出于这个原因，大多数共享主机公司都不提供 NoSQL。你必须注册一个 VPS 或运行自己的专用服务器。另一方面，SQL 主要是在服务器上运行。初期的工作都很顺利，但随着数据库需求的增加，硬件必须扩大。单个大型服务器比多个小型服务器昂贵得多，价格呈指数增长。所以在这种企业计算场景下，使用 NoSQL 更为划算，例如那些由谷歌和 Facebook 使用的服务器。

⑧ 数据库的性能方面的东西

1.应该是根据所建立信息系统客户的人数、预算的总数据量、平均访问量选择数据库。
2.性能指标就比较多了，你可以考虑一下数据库的可移植性（适用于不同的操作系统平台），数据库的并发性（同时操作一条数据或者一张表时数据的锁定方式），还有就是数据库的恢复能力（在出现异常数据能够最快完成恢复及备份的时间）。 --还有安全性,这个也很重要

300个人左右的b/s系统我推荐db2，并发性比sqlserver高，你要用常用的话甲骨文也可以，一般c/s系统都用sqlserver（中），access、mysql（小）

如果要说特点,真的是太多了，10000个字都不够写,你如果要买他们的产品,可以上网站或者找售前帮你

价格的话:sqlserver正版的大概就是10来万,db2要买服务,基本一年是15万到20万(基本服务),面向的应用我上面说了,b/s系统适合db2和甲骨文

这个性能是无法度量的,还要看你应用的情况,db2的应用最大的数据量理论上可以上亿,只要你数据库设计得合理,软件可以不要钱,基本服务一年是15到20万,不包括数据仓库,软件就是靠的增值服务,但是你不买服务就没有技术支持,而且商用的话你也有风险

如果你非要把其他搜到的东西列在这里,什么具体性能指标也没什么意义,还不如看ibm的db2白皮书,以我的经验来看,你应用在300个人在500个人的在线量,百万条数据,同时访问数据库,用db2不存在什么大的负载,非要说什么特点的话,就是一个字贵,db2的硬件的要求比较高,最好能上存储.

sqlserver存在一些安全性问题,而且大多数都运行在windows平台,对安全性的要求都不一样,你去了解一下aix就知道了

⑨ 数据库性能优化主要包括哪些方面

包括网络、硬件、操作系统、数据库参数和应用程序。

数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。

根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来只占数据库系统性能提升的40%左右，其余的60%系统性能提升来自对应用程序的优化。许多优化专家认为，对应用程序的优化可以得到80%的系统性能的提升。

(9)数据库性能扩展阅读

数据库性能优化法则归纳为5个层次：

1、减少数据访问（减少磁盘访问）

2、返回更少数据（减少网络传输或磁盘访问）

3、减少交互次数（减少网络传输）

4、减少服务器CPU开销（减少CPU及内存开销）

5、利用更多资源（增加资源）

由于每一层优化法则都是解决其对应硬件的性能问题，所以带来的性能提升比例也不一样。传统数据库系统设计是也是尽可能对低速设备提供优化方法，因此针对低速设备问题的可优化手段也更多，优化成本也更低。

任何一个SQL的性能优化都应该按这个规则由上到下来诊断问题并提出解决方案，而不应该首先想到的是增加资源解决问题。

⑩ 数据库的性能是由什么来衡量

数据库检索的速度