mysql数据库突然变慢 数据库变慢是什么原因

发布网友 发布时间：2022-04-23 05:37

我来回答

共3个回答

懂视网 时间：2022-04-30 03:47

前几天给公司的开发人员虚拟出来一台mysql服务器，使用ssh登录后show databases、show tables都很快，但是同事使用连接工具连接数据

库需要等几秒，用程序连接mysql，可能等上半分钟甚至更长，白白耽误开发人员的时间。

开发人员和运维都在同一局域网，网速没问题，排除了网的问题。虚拟出来的服务器，又加了2G内存，问题依然没解决。百度一下，找到了一

个解决方法，就是禁掉mysql对外部连接进行DNS解析。

vi /etc/my.cnf文件

[mysqld]

skip-name-resolve

表示跳过反向解析

发生上述情况的原因在于mysql服务器在接收到一个远程ip访问的时候，默认会去查该ip的反向解析，这个反查的过程会比较慢，如果该ip没

有反解，mysql也有可能会卡死在这个连接上。

禁止MySQL对外部连接进行DNS解析，从而导致mysql中出现大量状态为Connect的连接，影响mysql使用。使用这一选项可以消除MySQL进行DNS

解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！

在mysql官网上找到了关于mysql如何使用DNS的解释，如下：

When a new thread connects to mysqld, mysqld will span 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. 

链接地址：http://live.dadanini.at/cds/mysql/doc/D/N/DNS.html

本文出自 “Jacky鑫” 博客，请务必保留此出处http://jackyxin.blog.51cto.com/1976631/1662254

mysql连接慢的问题

标签：mysql连接、dns

热心网友 时间：2022-04-30 00:55

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

热心网友 时间：2022-04-30 02:13

可能是某个程序有问题，比如连接数据库之后不释放，造成无数的数据库进程，那样数据库就会越来越慢，甚至无法连接。
出现故障的时候，你NETSTAT -N查看一下网络连接，看看是不是许多3306的TCP连接。同时也可以在mysql里面使用show processlist查看有多少数据库进程，以及这些进程正在进行什么操作。