专业编程培训机构——完成蜕变以后轻松拿高薪
电话+V：159999-78052 ，欢迎咨询数据库服务老是带宽不够，[python实用课程]，[C++单片机原理]，[C#网站搭建]，[Nodejs小程序开发]，[ios游戏开发]，[安卓游戏开发]，[教会用大脑用想法赚钱实现阶层跨越]
一、哪些因素会对mysql数据库服务器性能造成影响
网络宽带也会有所影响。
网络是数据库基础架构的主要部分。但是，通常性能基准测试是在本地计算机上完成的，客户端和服务器并置在一起。这样做是为了简化结构并排除一个以上的变量（网络部分），但是我们也忽略了网络对性能的影响。对于像MySQLGroupReplication这样的产品集群来说，网络更为重要。在这篇文章中，我将介绍网络设置。这些都是简单而微不足道的，但却是让我们更了解复杂网络设置效果的基石。
安装我将使用两台裸机服务器，通过专用的10Gb网络连接。我将通过使用ethtool-seth1speed1000duplexfullautonegoff命令更改网络接口速度来模拟1Gb网络。
我将运行一个简单的基准：sysbencholtp_read_only--mysql-ssl=on--mysql-host=172.16.0.1--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开销。操作系统：Ubuntu16.04
N1基准-网络带宽在第一个实验中，我将比较1Gb网络和10Gb网络。显然，1Gb网络性能是这里的瓶颈，如果我们迁移到10Gb网络，我们可以显着改善我们的结果。要查看1Gb网络是瓶颈，我们可以检查PMM（percona的数据库监控管理开源工具）中的网络流量图表：
我们可以看到我们的吞吐量达到了116MiB/s（或928Mb/s)，这非常接近网络带宽。但是，如果我们的网络基础设施仅限于1Gb，我们可以做些什么？
N2基准-协议压缩MySQL协议中有一个功能，您可以看到客户端和服务器之间的网络交换压缩：--mysql-compression=on。让我们看看它将如何影响我们的结果。
这是一个有趣的结果。当我们使用所有可用的网络带宽时，协议压缩实际上有助于改善结果。
但是10Gb网络不是这种情况。压缩/解压缩所需的CPU资源是一个限制因素，通过压缩，吞吐量实际上只达到我们没有压缩的一半。现在让我们谈谈协议加密，以及如何使用SSL影响我们的结果。
N3基准-网络加密
对于1Gb网络，SSL加密显示了一些损失-单线程约为10％-但是否则我们再次达到带宽限制。我们还看到了大量线程的可扩展性，这在10Gb网络案例中更为明显。使用10Gb时，SSL协议在32个线程后不会扩展。实际上，它似乎是MySQL目前使用的OpenSSL1.0中的可伸缩性问题。在我们的实验中，我们看到OpenSSL1.1.1提供了更好的可伸缩性，但是您需要从链接到OpenSSL1.1.1的源代码中获得特殊的MySQL构建才能实现这一点。我没有在这里展示它们，因为我们没有生产二进制文件。
结论
1.网络性能和利用率将影响一般应用程序吞吐量。
2.检查您是否达到了网络带宽限制。
3.如果受到网络带宽的限制，协议压缩可以改善结果，但如果不是，则可能会使事情变得更糟。
4.SSL加密在线程数量较少的情况下会有一些损失（约10％），但对于高并发工作负载，它不会扩展。
二、联通机房数据库服务器需要多少带宽比较合适
这个看您具体情况了。
具体数据都是什么类型的数据，数据的大小，有多少终端在使用，您预计的每个终端要分配多少带宽。
如果是只是一些文字或者图片性质的数据，并且单个终端单次调用数据不是很大的，这个带宽就没有太大的影响，根据您的终端数10M到几十兆的都可以。
如果说你的数据库了里面的有大量的上传下载，那您就要考虑下每个终端需要多大的带宽了，您在综合下您的终端数，应该就可以得到一个需要的带宽数。
下载速度=带宽/8您可以根据这个来具体核算下。
数据库查询慢，让经验丰富的老程序员告诉你原因
2019-07-0113:04·狮范客
私信我或关注微信号：猿来如此呀，回复：学习，获取免费学习资源包。目录前言偶尔效率慢的情况原因一：刷新“脏”页原因二：数据被锁住一直都存在效率慢的情况原因一：查询的数据量太大原因二：没有用到索引
正文
回到顶部
前言
本文只但从数据库本身来看查询慢的可能因素，至于内存不够、网速较慢不属于本文讨论范畴。
本文内容参考自公众号文章：
腾讯面试：一条SQL语句执行得很慢的原因有哪些？---不看后悔系列
我对公众号中的内容作自己的梳理总结
开始
首先要分类讨论一下，这条查询语句是在偶尔的情况下查询效率慢，还是一直都存在查询效率慢的问题。
对于第一种情况，可能查询语句本身没有问题，是数据库遇到了其他问题；
对于第二种情况，应该是查询语句出了问题，需要优化
回到顶部
偶尔效率慢的情况
原因一：刷新“脏”页
什么是“脏”页
当对数据库进行插入或者更新操作时，数据库会立刻将内存的数据页上的信息更新，但是不会立刻将将更新的数据存到磁盘上，而是先保存到redolog中，等合适的时机在将redolog的信息存储到磁盘上
针对这种内存中的数据页和磁盘上的数据不同的情况我们将内存中的数据页称为“脏”页，而内存中和磁盘上数据相同的情况则称为“干净”页。
刷新“脏”页时，系统会暂停其他的操作，全身心的将数据存到磁盘中，就会导致平常正常执行的mysql语句变慢
什么时候会刷新“脏”页
case1：redolog装满时
case2：内存不够用时
case3：mysql认为系统空闲时
case4：mysql正常关闭时
原因二：数据被锁住
可以用showprocesslist命令查看一下语句执行的状态，查看要查询的数据是否被锁住
回到顶部
一直都存在效率慢的情况
原因一：查询的数据量太大
查看是否查询了不必要的行与列，避免用select*fromtable这样的语句
原因二：没有用到索引
当数据量很大时，若没有用索引采用全表索引是很耗费时间的。而这里没有用到索引由可以分多钟情况
case1：没有建索引
case2：索引失效
引起索引失效的可能原因
1）在索引列上用了内置函数或者其他+-*/运算
2）用通配符开头
3）多列索引违背最佳最匹配原则
4）or操作符容器造成索引失效，除非or的每个操作列都有索引
5）字符串不加单引号
case3：系统选错索引
系统选错索引其实是索引失效的一种形式，但是由于涉及到的知识点较多，所以单独拿出来分析。
系统选错索引导致索引失效时系统将全表扫描与用索引要扫描的行数进行比较，若是觉得运用索引反而要复杂，则系统就会放弃索引采用全表扫描的方式。
那么什么时候会出现运用索引反而比全表扫描效率更低的情况呢？
首先我们都知道主键索引保存的是整行数据，而非主键索引保存的是主键的值。所以运用非主键索引时要先定位到满足条件的行的主键值，在由主键值拿到整行数据的信息，要经过两次索引的过程。
极端情况下，当索引寻找的数据条件全表都满足时，则此时索引寻找相比于全表扫描反而多了一系列索引过程。
所以系统在判断是否需要应用索引时会先判断如果运用索引大致需要扫描多少行，如果系统预测要扫描的行数很多，则系统会选择放弃索引采取全表扫描的方式。
系统如何判断运用索引需要扫描的行数？这就需要用到索引的区分度。索引的区分度又称为基数，一个索引上不同的值越多，意味着出现相同数值的索引越少，意味着索引的区分度越高。
区分度越高，则满足索引查询条件的数据就越少，则系统预测扫描的函数不多。
那么索引的区分度又是如何得来的呢？
采样。系统通过采样的方式来推测索引的区分度。既然是采样则就会有误差，如果你想避免这种误差，不想要系统进行这种它认为的人性化的选择方式，你可以强制运用索引
select*fromtindex(a)wherec>100andc<1000;
你也可用下面的第一行命令查看索引的基数，如果基数和实际不符合的话你也可用第二行命令让系统重新采样计算索引基数
1showindexfromt;2analyzetablet;
可以用explain+SQL查询语句来查看SQL语句的执行过程，查看是否用到了预期索引
来源网络，侵权联系删除
私信我或关注微信号：猿来如此呀，回复：学习，获取免费学习资源包。
【WINDRISES EMPLOYMENT PROGRAMMING】尊享对接老板
电话+V：159999-78052
机构由一批拥有10年以上开发管理经验，且来自互联网或研究机构的IT精英组成，负责研究、开发教学模式和课程内容。公司具有完善的课程研发体系，一直走在整个行业发展的前端，在行业内竖立起了良好的品质口碑。
