本文目录一览：
- 1、PHP连接远端mysql很慢，要5-10秒，修改了my.cnf配置文件还是没用
- 2、MySQL数据库服务器逐渐变慢分析与解决方法分享
- 3、访问外网的mysql数据库比较慢是怎么解决
- 4、MYSQL跨服务器跨库关联表查询很慢怎么解决
- 5、MySQL数据库服务器逐渐变慢 该如何分析与解决
PHP连接远端mysql很慢，要5-10秒，修改了my.cnf配置文件还是没用
这个问题我遇到过，一般出现这种情况都是DNS反解析问题，还有SSH连接过慢问题也是。
搞定的方法，就是加入google的DNS：8.8.8.8
windows系统可以配置第备用DNS为8.8.8.8
Linux系统可以配置为nameserver 8.8.8.8
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数据库比较慢是怎么解决
服务器放在局域网内进行测试时，数据库的访问速度还是很快。但当服务器放到外网后，数据库的访问速度就变得非常慢。
后来在网上发现解决方法,my.ini里面添加
[mysqld]
skip-name-resolve
这样速度就快了!
skip-name-resolve
选项就能禁用DNS解析，连接速度会快很多。不过，这样的话就不能在MySQL的授权表中使用主机名了而只能用ip格式。
就MySQL本身而言，问题出在在mysql dns反解析
mysqlshow processlist;
| 20681949 | unauthenticated user | 10.10.4.193:52497 | NULL | Connect | | Reading from net | NULL |
| 20681948 | unauthenticated user | 10.10.4.193:52495 | NULL | Connect | | Reading from net | NULL
发现有非常多的 unauthenticated user 尝试做登入使用 mysql 的情况 ，当这种情况无限制发生时就会造成系统十分缓慢。
查阅mysql官方网站得知，这属于官方一个系统上的特殊设定，就把他当成mysql的一个bug算了，不管链接的的方式是经过 hosts 或是 IP 的模式，他都会对 DNS 做反查。mysqld 会尝试去反查 IP - dns ，由于反查解析过慢，就会无法应付过量的查询。
MYSQL跨服务器跨库关联表查询很慢怎么解决
CSDN官方APP
中国专业的IT社区立即下载
CSDN首页
博客
学院
下载
GitChat
论坛
APP
问答
商城
VIP
活动
招聘
ITeye
TinyMind
专题
Copyright © 1999-2019,
CSDN.NET, All Rights Reserved
crimeheaven的专栏
登录
crimeheaven关注 访问量 6万+ 原创 22 博主更多文章
转 mysql跨库操作速度慢的解决方案
crimeheaven阅读数：24752014-03-14
远程连接mysql速度慢的解决方法:skip-name-resolve取消DNS的反向解析
PHP远程连接MYSQL速度慢,有时远程连接到MYSQL用时4-20秒不等,本地连接MYSQL正常,出现这种问题的主要原因是,默认安装的MYSQL开启了DNS的反向解析,在MY.INI(WINDOWS系统下)或MY.CNF(UNIX或LINUX系统下)文件的[mysqld]下加入skip-name-resolve这一句。
但是，这样会引起一个问题：连接mysql时，不能使用 localhost连接了，而是要使用IP地址的；如果是按localhost对用户赋权限的话，用户登录权限也要修改一下的。
连接mysql速度慢的解决方法.
2台服务器，一台跑iis+php，一台跑mysql，和以往一样配置好环境，测试页面一切OK
跑应用的时候发现php访问mysql速度很慢，这种情况在以前从未发现过，虽然2台服务器并非在同一网段中，但是ping数值基本上都在1,2ms之间，tcp连接应该不是问题关健，google以后找到答案，在my.ini文件的[mysqld]部分加入:skip-name-resolve，保存文件，重启mysql，一切OK啦，速度象飞一样了
新版本的mysql配置起来不象以前的那个傻瓜化了，这个问题折腾了我一上午的时间，晚上回来总算是解决了，嘿嘿，又学到一些东西。
Windows 2003下的MySQL 5服务器，本机连接到MySQL服务非常快，局域网内有两台Linux机器，有一台连接很快，另外一台输入密码后要等好几秒钟才能连上。
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 变量，想法破灭。
