mysql下载慢（远程连接mysql数据库很慢，修改了my.ini配置文件，[mysqld]下加了skip-name-resolve并重启也没有用）

本文目录

• 远程连接mysql数据库很慢，修改了my.ini配置文件，[mysqld]下加了skip-name-resolve并重启也没有用
• 如何解决局域网内mysql数据库连接慢
• 为什么连接本地mysql数据库很慢
• MySQL数据库服务器逐渐变慢分析与解决方法分享
• 如何解决mysql 查询和更新速度慢
• brew install mysql 非常慢是怎么回事
• mysql下载初始化数据库失败
• MySQL数据库服务器逐渐变慢 该怎么分析与解决
• mysql数据库突然变慢 数据库变慢是什么原因

远程连接mysql数据库很慢，修改了my.ini配置文件，[mysqld]下加了skip-name-resolve并重启也没有用

看看远程数据库和程序数据库是否在同一服务器。
如不在同一服务器，测试一下与远程数据库服务器的连接速度。
如在同一服务器，就是MY.INI设置问题。

如何解决局域网内mysql数据库连接慢

通过内网连另外一台机器的mysql服务， 确发现速度N慢！ 等了大约几十秒才等到提示输入密码。 但是ping mysql所在服务器却很快！ 想到很久之前有过类似的经验， telnet等一些服务在连接请求的时候，会做一些反向域名解析（如果反向解析不顺畅， 估计就会延迟很多， 给人的感觉是连接速度N慢！）
在网上搜索了下解决办法， 发现有两种：
一. 两边机器配置的resolve.conf不一样， 把resolve.conf配置成速度比较快的DNS就OK
二. 把mysql配置中的DNS反向解析关掉， 也OK
我用的是第一种办法， 修改resolve.conf配置后， 速度就上来了！
***隐藏网址***
两台在同一网段的机器, 连接同一个数据库服务器, 一台的速度是另一台的100倍, 数据库主机是域名表示的. 怎么都想不明白?
后来查看两台机器的 /etc/resolv.conf, 发现配置不一样, 改成速度快的那台机器的配置, 速度那上就上来了.
域名解析也可以导致网络程序慢, 又一收获. 另外, mysql还有DNS反向解析的问题, 也可能导致速度慢, 可以在mysql的配置文件中, 把DNS反向解析关掉.
附二： 摘自
当远程访问mysql时，mysql会解析域名，会导致访问速度很慢，加上下面这个配置可解决此问题
# 禁止mysql做域名解析

skip-name-resolve
PHP远程连接MYSQL速度慢,有时远程连接到MYSQL用时4-20秒不等,本地连接MYSQL正常,出现这种问题的主要原因是,默认安装的MYSQL开启了DNS的反向解析,在MY.INI(WINDOWS系统下)或MY.CNF(UNIX或LINUX系统下)文件的下加入skip-name-resolve这一句。
但是，这样会引起一个问题：连接mysql时，不能使用 localhost连接了，而是要使用IP地址的；如果是按localhost对用户赋权限的话，用户登录权限也要修改一下的。
连接mysql速度慢的解决方法.
2台服务器，一台跑iis+php，一台跑mysql，和以往一样配置好环境，测试页面一切OK
跑应用的时候发现php访问mysql速度很慢，这种情况在以前从未发现过，虽然2台服务器并非在同一网段中，但是ping数值基本上都在1,2ms之间，tcp连接应该不是问题关健，google以后找到答案，在my.ini文件的部分加入:skip-name-resolve，保存文件，重启mysql，一切OK啦，速度象飞一样了
新版本的mysql配置起来不象以前的那个傻瓜化了，这个问题折腾了我一上午的时间，晚上回来总算是解决了，嘿嘿，又学到一些东西。
Windows 2003下的MySQL 5服务器，本机连接到MySQL服务非常快，局域网内有两台Linux机器，有一台连接很快，另外一台输入密码后要等好几秒钟才能连上。
解决办法：
在MySQL服务器的配置中增加一个如下配置后速度飞快。
skip-name-resolve
附录：( How MySQL uses DNS )
When a new thread connects to mysqld, mysqld will spawn a new thread to handle the request. This thread will first check if the hostname is in the hostname cache. If not the thread will call gethostbyaddr_r() and gethostbyname_r() to resolve the hostname.
If the operating system doesn’t support the above thread-safe calls, the thread will lock a mutex and call gethostbyaddr() and gethostbyname() instead. Note that in this case no other thread can resolve other hostnames that is not in the hostname cache until the first thread is ready.
You can disable DNS host lookup by starting mysqld with --skip-name-resolve. In this case you can however only use IP names in the MySQL privilege tables.
If you have a very slow DNS and many hosts, you can get more performance by either disabling DNS lookop with --skip-name-resolve or by increasing the HOST_CACHE_SIZE define (default: 128) and recompile mysqld.
You can disable the hostname cache with --skip-host-cache. You can clear the hostname cache with FLUSH HOSTS or mysqladmin flush-hosts.
If you don’t want to allow connections over TCP/IP, you can do this by starting mysqld with --skip-networking.
PHP远程连接MYSQL速度慢,有时远程连接到MYSQL用时4-20秒不等,本地连接MYSQL正常,出现这种问题的主要原因是,默认安装的MYSQL开启了DNS的反向解析,在MY.INI(WINDOWS系统下)或MY.CNF(UNIX或LINUX系统下)文件的下加入skip-name-resolve这一句。
MYSQL远程连接速度慢的解决方法
在局域网内连接其他机器的MYSQL,发现速度慢的很,不知道什么原因,总有几秒的延迟.
后来在网上发现解决方法,my.ini里面添加

skip-name-resolve
skip-grant-tables
这样速度就快了!
skip-name-resolve
选项就能禁用DNS解析，连接速度会快很多。不过，这样的话就不能在MySQL的授权表中使用主机名了而只能用ip格式。
若使用_skip-grant-tables系统将对任何用户的访问不做任何访问控制，但可以用 mysqladmin flush-privileges或mysqladmin reload来开启访问控制;默认情况是show databases语句对所有用户开放，如果mysql服务器没有开远程帐户，就在my.ini里面加上skip-grant-tables
通过以上方法成功解决局域网内mysql数据库连接慢，有需要的朋友可以参考下本篇文章。


您可能感兴趣的文章:mysql服务器查询慢原因分析与解决方法小结MYSQL速度慢的问题 记录数据库语句远程连接mysql数据库注意事项记录(远程连接慢skip-name-resolve)根据mysql慢日志监控SQL语句执行效率mysql 开启慢查询 如何打开mysql的慢查询日志记录关于mysql innodb count(*)速度慢的解决办法MySQL慢查询查找和调优测试PHP连接局域网MYSQL数据库的简单实例mysql正确安全清空在线慢查询日志slow log的流程分享

为什么连接本地mysql数据库很慢

有两个myslq数据库，分别装在了两个服务器上，即210&249；
其他服务器上连接数据库，发现249的数据库连接很慢，而210正常；结果是：249数据库出了问题。
尝试的解决办法：1.重启apache （在/usr/local/apache/bin 下 apachectl -k restart) 不管用；2.重启数据库所在服务器（在Linux下输入reboot）不管用；
3.在网上搜帖子“连接mysql数据库速度很慢的原因，发现mysql就会试图去解析来访问的机器的domain name,在经历一段时间后才取出数据．在网上找了很久才发现，一个参数：skip-name-resolve,在mysql的配置文件my.cnf中,在下面加上这个配置就可以了．前不久断网时登录内类系统后台奇慢的问题，也是由这个原因引起的。”
首先找到mysql的配置文件my.cnf，在/etc/下，按照帖子的方法，修改【mysqld】，加上了skip-name-resolve；然后重启MySQL，先关闭：在/bin/下 mysqladmin -uroot -p密码 shutdown， ps aux|grep mysql 观察mysql是否被关闭，启动：mysqld_safe &；重启过后，管用
访问速度很快~~
这里推荐安全的重启方法
$mysql_dir/bin/mysqladmin -u root -p shutdown
$mysql_dir/bin/safe_mysqld &
mysqladmin和mysqld_safe位于Mysql安装目录的bin目录下，很容易找到的。

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
　　0
0
72
25428
54712672264
0
0
14
43
53
59
1
198
0
0
　　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 查询和更新速度慢

问题

我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 5.7 上运行特别慢，怎么办?

实验

我们搭建一个 MySQL 5.7 的环境，此处省略搭建步骤。

写个简单的脚本，制造一批带主键和不带主键的表：

执行一下脚本：

现在执行以下 SQL 看看效果：

...

执行了 16.80s，感觉是非常慢了。

现在用一下 DBA 三板斧，看看执行计划：

感觉有点惨，由于 information_schema.columns 是元数据表，没有必要的统计信息。

那我们来 show warnings 看看 MySQL 改写后的 SQL：

我们格式化一下 SQL：

可以看到 MySQL 将

select from A where A.x not in (select x from B) //非关联子查询

转换成了

select from A where not exists (select 1 from B where B.x = a.x) //关联子查询

如果我们自己是 MySQL，在执行非关联子查询时，可以使用很简单的策略：

select from A where A.x not in (select x from B where ...) //非关联子查询:1. 扫描 B 表中的所有记录，找到满足条件的记录，存放在临时表 C 中，建好索引2. 扫描 A 表中的记录，与临时表 C 中的记录进行比对，直接在索引里比对，

而关联子查询就需要循环迭代：

select from A where not exists (select 1 from B where B.x = a.x and ...) //关联子查询扫描 A 表的每一条记录 rA：     扫描 B 表，找到其中的第一条满足 rA 条件的记录。

显然，关联子查询的扫描成本会高于非关联子查询。

我们希望 MySQL 能先"缓存"子查询的结果（缓存这一步叫物化，MATERIALIZATION），但MySQL 认为不缓存更快，我们就需要给予 MySQL 一定指导。

...

可以看到执行时间变成了 0.67s。

整理

我们诊断的关键点如下：

\1. 对于 information_schema 中的元数据表，执行计划不能提供有效信息。

\2. 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。

\3. 我们增加了 hint，指导 MySQL 正确进行优化判断。

但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断。

brew install mysql 非常慢是怎么回事

方法： 1。 改表法。可能是你的帐号不允许从远程登陆，只能在localhost。这个时候只要在localhost的那台电脑，登入mysql后，更改 "mysql" 数据库里的 "user" 表里的 "host" 项，从"localhost"改称"%" mysql -u root -pvmwaremysql》use mysql;mysql》update user set host = ’%’ where user = ’root’;mysql》select host, user from user; 2. 授权法。例如，你想myuser使用mypassword从任何主机连接到mysql服务器的话。

mysql下载初始化数据库失败

网络错误、版本兼容性问题、安全软件阻止。根据查询IT虾米网显示。
1、网络错误。下载初始数据库需要连接到MySQL的官网或其他网站。网络不稳定或者速度过慢，就可能导致下载失败。
2、版本兼容性问题。有时候MySQL的版本和下载的初始数据库版本不兼容，就会导致下载失败。
3、安全软件阻止。许多安全软件可能会阻止MySQL下载和安装初始数据库，以保护用户设备免受潜在威胁。

MySQL数据库服务器逐渐变慢 该怎么分析与解决

我们先来看第一个阶段，MySQL慢的诊断思路，一般我们会从三个方向来做：

• 第一个方向是MySQL内部的观测

• 第二个方向是外部资源的观测

• 第三个方向是外部需求的改造

1.1 MySQL 内部观测

我们来看MySQL内部的观测，常用的观测手段是这样的，从上往下看，第一部分是Processlist，看一下哪个SQL压力不太正常，第二步是explain，解释一下它的执行计划，第三步我们要做Profilling，如果这个SQL能再执行一次的话, 就做一个Profilling，然后高级的DBA会直接动用performance_schema ，MySQL 5.7 以后直接动用sys_schema，sys_schema是一个视图，里面有便捷的各类信息，帮助大家来诊断性能。再高级一点，我们会动用innodb_metrics进行一个对引擎的诊断。

除了这些手段以外，大家还提出了一些乱七八糟的手段，我就不列在这了，这些是常规的一个MySQL的内部的状态观测的思路。除了这些以外，MySQL还陆陆续续提供了一些暴露自己状态的方案，但是这些方案并没有在实践中形成套路，原因是学习成本比较高。

1.2 外部资源观测


外部资源观测这部分，我引用了一篇文章，这篇文章的二维码我贴在上面了。这篇文章是国外的一个神写的，标题是：60秒的快速巡检，我们来看一下它在60秒之内对服务器到底做了一个什么样的巡检。一共十条命令，这是前五条，我们一条一条来看。

1.uptime，uptime告诉我们这个机器活了多久，以及它的平均的负载是多少。


2.dmesg -T | tail，告诉我们系统日志里边有没有什么报错。

3.vmstat 1，告诉我们虚拟内存的状态，页的换进换出有没有问题，swap有没有使用。

4. mpstat -P ALL，告诉我们CPU压力在各个核上是不是均匀的。

5.pidstat 1，告诉我们各个进程的对资源的占用大概是什么样子。


我们来看一下后五条：

首先是iostat-xz 1，查看IO的问题，然后是free-m内存使用率，之后两个sar，按设备网卡设备的维度，看一下网络的消耗状态，以及总体看TCP的使用率和错误率是多少。最后一条命令top，看一下大概的进程和线程的问题。

这个就是对于外部资源的诊断，这十条命令揭示了应该去诊断哪些外部资源。

1.3 外部需求改造

第三个诊断思路是外部的需求改造，我在这里引用了一篇文档，这篇文档是MySQL的官方文档中的一章，这一章叫Examples of Common Queries，文档中介绍了常规的SQL怎么写, 给出了一些例子。文章的链接二维码在slide上。

我们来看一下它其中提到的一个例子。

它做的事情是从一个表里边去选取，这张表有三列，article、dealer、price，选取每个作者的最贵的商品列在结果集中，这是它的最原始的SQL，非常符合业务的写法，但是它是个关联子查询。

关联子查询成本是很贵的，所以上面的文档会教你快速地把它转成一个非关联子查询，大家可以看到中间的子查询和外边的查询之间是没有关联性的。

第三步，会教大家直接把子查询拿掉，然后转成这样一个SQL，这个就叫业务改造，前后三个SQL的成本都不一样，把关联子查询拆掉的成本，拆掉以后SQL会跑得非常好，但这个SQL已经不能良好表义了，只有在诊断到SQL成本比较高的情况下才建议大家使用这种方式。

为什么它能够把一个关联子查询拆掉呢？

这背后的原理是关系代数，所有的SQL都可以被表达成等价的关系代数式，关系代数式之间有等价关系，这个等价关系通过变换可以把关联子查询拆掉。

上面的这篇文档是一个大学的教材，它从头教了关于代数和SQL之间的关系。然后一步步推导怎么去简化这句SQL。

第一，MySQL本身提供了很多命令来观察MySQL自身的各类状态，大家从上往下检一般能检到SQL的问题或者服务器的问题。

第二，从服务器的角度，我们从巡检的脚本角度入手，服务器的资源就这几种，观测手法也就那么几种，我们把服务器的资源全部都观察一圈就可以了。

第三，如果实在搞不定，需求方一定要按照数据库容易接受的方式去写SQL，这个成本会下降的非常快，这个是常规的MySQL慢的诊断思路。

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 变量，想法破灭。