mysql下载怎么这么慢,mysql下载速度太慢

MySQL数据库服务器逐渐变慢分析与解决方法分享

一、检查系统的状态

专注于为中小企业提供成都网站制作、成都网站设计服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业潞城免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了成百上千家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

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

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

#sar-u210—

即每隔2秒检察一次，共执行20次。

结果示例：

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

Linux2.4.21-20.ELsmp

(YY075)05/19/2005

10:36:07AMCPU%user%nice%system%idle

10:36:09AMall0.000.000.1399.87

10:36:11AMall0.000.000.00100.00

10:36:13AMall0.250.000.2599.49

10:36:15AMall0.130.000.1399.75

10:36:17AMall0.000.000.00100.00

其中：

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

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

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

%idle即空闲的百分比。

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

2.使用vmstat监控内存

cpu资源

[root@mysql1

~]#

vmstat

procs

———–memory———-—swap–

—–io—-–system–

—–cpu——

r

b

swpd

free

buff

cache

si

so

bi

bo

in

cs

us

sy

id

wa

st

72

25428

54712672264

14

43

53

59

1

198

vmstat

的输出那些信息值得关注?

io

bo:

磁盘写的数据量稍大，如果是大文件的写，10M以内基本不用担心，如果是小文件写2M以内基本正常

①

CPU问题

下面几列需要被察看，以确定cpu是否有问题

Processesinthe

run

queue

(procs

r)

Usertime

(cpu

us)

System

time

(cpu

sy)

Idle

time

(cpu

id)

问题情况:

如果processes

in

run

queue

(procs

r)的数量远大于系统中cpu的数量，将会使系统便慢。

如果这个数量是cpu的4倍的话，说明系统正面临cpu能力短缺,这将使系统运行速度大幅度降低

如果cpu的idle时间经常为0的话，或者系统占用时间(cpu

sy)是用户占用时间(cpu

us)两辈的话，系统面临缺少cpu资源

解决方案

:

解决这些情况，涉及到调整应用程序，使其能更有效的使用cpu，同时增加cpu的能力或数量

②内存问题

主要查看页导入的数值(swap中的si)，如果该值比较大就要考虑内存，大概方法如下：

最简单的，加大RAM

减少RAM的需求

3.磁盘IO问题

处理方式：做raid10提高性能

4.网络问题

telnet一下MySQL对外开放的端口，如果不通的话，看看防火墙是否正确设置了。另外，看看MySQL是不是开启了skip-networking的选项，如果开启请关闭。

mysql奇慢无比, 求大神指点

mysql的其他数据查询是否也比较慢

在mysql里调整运行参数,简单的方法,是启动时选择不通的my**.ini

MySQL查询效率很慢的问题如何分析和解决

MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。

如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。

临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。

docker下载mysql下载不下来

网络问题。docker对网络环境的要求高，若是为网络环境差mysql下载不下来。Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Linux或Windows操作系统的机器上，也可以实现虚拟化。

mysqlexecutebatch效率慢

mysqlexecutebatch效率慢

1. 数据查询过慢一般是索引问题，可能是因为选错索引，也可能是因为查询的行数太多。

2.客户端和数据库连接数过小，会限制sql的查询并发数，增大连接数可以提升速度。

3.innodb里会有一层内存buffer pool用于提升查询速度，命中率一般99%，如果低于这个值，可以考虑增大buffer pool的大小，这样也可以提升速度。

load MySQL极慢，为什么

第一次计算的耗时，主要还是花在了加载DLL上；我们是这么做的，在下面的事件里先实例化要用到的类 public Form1() { InitializeComponent(); public myClass mc; } 这样就把加载动作放到了窗体生成事件中，调用的时候自然就快了。 但是加载的东...