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

以MySQL为例：

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

1、sql查询速度

2、网卡流量

3、服务器硬件

4、磁盘IO

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

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

相关内容拓展：

1、SQL查询速度

风险：效率低下的SQL

2、网卡流量

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

方案：

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

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

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

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

3、磁盘IO

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

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

ping值一般没人去做假 最多是给域名加DNS 从哪儿PING速度都快一些 不过相应的网站打开速度也快了
不管你用单线或者双线 一般都有限制 就是上限带宽 比如10M 5M的 除非你有熟人 可以照顾你 不限你使用 或者你多掏钱 你想 带宽上限都被限了 如果你的流量非常大 访问量很多的话 肯定会影响响应速度 这点你还要注意自己的服务器硬件配置 硬件如果太低的话 处理不过来很多数据 也会影响响应速度
目前已知最快的网站 没有 只有相对的 全世界没有一个网站可以满足所有人的要求 达到所谓的最快 只有相对来说

服务器不稳定的主要原因：
一：本地网络问题
如果我们在访问网站的时候突然发现很慢，很卡。我们首先要做的就是检查一下自身本地的网络环境是不是有问题。可以利用ping一下已知的知名域名，ping值出来之后，如果ping值很大，则可能是自己本地的网络环境有问题。反之ping值小，则是美国服务器出现问题了。
二：所在机房问题
网站加载速度过慢时，如果确认本地网络没有问题，还有可能是问题出现在美国服务器所在机房，机房的设备是完善的，但是也不能避免机房出现异常。当机房受到恶意攻击的时候，也会导致美国服务器变慢。另外也要检查一下机房的主干网络是否有异常。如果美国服务器托管了，那么我们可以联系机房的运维人员排查一下什么问题，推荐相关阅读：选择美国服务器应该注意哪些事项
三：运营商国际路由问题
当我们所使用的网络，运行商的路由或者提供的服务出现问题也会导致美国服务器变慢。特别是我们使用国外美国服务器的用户会经常遇到这类问题。当数据在传输的过程中，出现丢包或者无法连接路由时，用到这类网线的美国服务器速度就会很慢。这种情况并不是美国服务器本身出现问题，也不是本地网络出现问题，只需要等运营商修复网络即可。
四：资源不足和美国服务器中毒
我们要知道当美国服务器剩余空间不足时，会导致程序在运行的时候cpu或者内存过载，导致美国服务器速度变慢。遇到这类问题，我们可以尝试优化系统，关闭美国服务器上没必要运行的软件和程序。如果此类事件经常发生，那么我们就应该要升级美国服务器的整体配置了。另外，美国服务器如果遭受到恶意攻击也会导致美国服务器变慢。所以我们选择美国服务器的防火墙和所在机房的安全防护级别也是至关重要的。

网络宽带也会有所影响。

网络是数据库基础架构的主要部分。但是，通常性能基准测试是在本地计算机上完成的，客户端和服务器并置在一起。这样做是为了简化结构并排除一个以上的变量（网络部分），但是我们也忽略了网络对性能的影响。对于像 MySQL Group Replication 这样的产品集群来说，网络更为重要。在这篇文章中，我将介绍网络设置。这些都是简单而微不足道的，但却是让我们更了解复杂网络设置效果的基石。

安装我将使用两台裸机服务器，通过专用的 10Gb 网络连接。我将通过使用 ethtool-s eth1 speed1000duplex full autoneg off 命令更改网络接口速度来模拟 1Gb 网络。

我将运行一个简单的基准：sysbench oltp_read_only --mysql-ssl=on --mysql-host=1721601 --tables=20 --table-size=10000000 --mysql-user=sbtest --mysql-password=sbtest --threads=$i --time=300 --report-interval=1 --rand-type=pareto
运行时线程数从 1 到 2048 不等。所有数据都适合内存 -innodb_buffer_pool_size 足够大。因此工作负载在内存中占用大量 CPU：没有 IO 开销。 *** 作系统：Ubuntu 1604

N1 基准-网络带宽在第一个实验中，我将比较 1Gb 网络和 10Gb 网络。显然，1Gb 网络性能是这里的瓶颈，如果我们迁移到 10Gb 网络，我们可以显着改善我们的结果。要查看 1Gb 网络是瓶颈，我们可以检查 PMM（percona 的数据库监控管理开源工具） 中的网络流量图表：

我们可以看到我们的吞吐量达到了 116 MiB/s（或 928 Mb/s)，这非常接近网络带宽。但是，如果我们的网络基础设施仅限于 1Gb，我们可以做些什么？

N2 基准-协议压缩MySQL 协议中有一个功能，您可以看到客户端和服务器之间的网络交换压缩：--mysql-compression=on。让我们看看它将如何影响我们的结果。

这是一个有趣的结果。当我们使用所有可用的网络带宽时，协议压缩实际上有助于改善结果。

但是 10Gb 网络不是这种情况。压缩/解压缩所需的 CPU 资源是一个限制因素，通过压缩，吞吐量实际上只达到我们没有压缩的一半。现在让我们谈谈协议加密，以及如何使用 SSL 影响我们的结果。

N3基准-网络加密

对于 1Gb 网络，SSL 加密显示了一些损失 - 单线程约为 10％ - 但是否则我们再次达到带宽限制。我们还看到了大量线程的可扩展性，这在 10Gb 网络案例中更为明显。使用 10Gb 时，SSL 协议在 32 个线程后不会扩展。实际上，它似乎是 MySQL 目前使用的 OpenSSL 10 中的可伸缩性问题。在我们的实验中，我们看到 OpenSSL 111 提供了更好的可伸缩性，但是您需要从链接到OpenSSL 111 的源代码中获得特殊的 MySQL 构建才能实现这一点。我没有在这里展示它们，因为我们没有生产二进制文件。

结论

1 网络性能和利用率将影响一般应用程序吞吐量。

2 检查您是否达到了网络带宽限制。

3 如果受到网络带宽的限制，协议压缩可以改善结果，但如果不是，则可能会使事情变得更糟。

4 SSL 加密在线程数量较少的情况下会有一些损失（约10％），但对于高并发工作负载，它不会扩展。

我们以Windows服务器、Linux服务器和IBM AIX服务器为例，分别说明如下：
Windows监控功能：
1、管理Windows的可用性和性能
2、监控性能统计数据，如CPU利用率、内存利用率、磁盘利用率和应答时间
3、监控Windows系统中运行的进程
4、如果Windows系统或该系统中任何指定的属性出现问题，将基于所配置的阈值生成通知和告警；基于配置自动执行 *** 作
5、能即刻呈现性能图表和报表；并基于可用性、健康状况和连接时间分别显示报表
6、提供历史的和当前的Windows性能指标，以便了解特定时间段内的性能状态
7、监控整体的CPU利用情况，并显示哪些进程正在消耗多少CPU资源
8、监控内存使用情况并检测内存消耗大户
Linux监控功能：
1、管理Linux的可用性和性能
2、监控性能统计数据，如CPU利用率、内存利用率、磁盘利用率和应答时间
3、监控Linux系统中运行的进程
4、如果Linux系统或该系统中任何指定的属性出现问题，将基于所配置的阈值生成通知和告警；并基于配置自动执行 *** 作
5、能即刻呈现性能图表和报表；并基于可用性、健康状况和连接时间分组和显示报表
6、提供历史的和当前的Linux性能指标，以便了解特定时间段内的性能状态
7、监控整体的CPU利用情况，并显示哪些进程正在占用多少CPU资源
8、监控内存使用情况并检测内存消耗大户
IBM AIX监控能力：
1、管理IBM AIX可用性和性能
2、监控诸如CPU利用率、内存利用率、磁盘利用率和应答时间等性能统计数据
3、监控模式包括Telnet和SSH
4、监控AIX系统上运行的进程
5、如果AIX系统或该系统中任何指定的属性出现问题，将基于所配置的阈值生成通知和告警；并基于配置自动执行 *** 作
6、能即刻呈现性能图表和报表；并基于可用性、健康状况和连接时间分组和显示报表
7、提供历史的和当前的AIX性能指标，以便了解特定时间段内的性能状态
8、监控整体的CPU利用情况，并显示哪些进程正在占用多少CPU资源
9、监控内存使用情况并检测内存消耗大户

---