mysql服务器连接很慢，mysql响应慢

本文内容列表：

• 1. MySQL数据库服务器逐渐变慢。如何分析和解决呢？
• 2、如何解决外网访问mysql数据库慢的问题？
• 3. MySQL数据库服务器逐渐变慢。如何分析和解决呢？

MySQL数据库服务器的速度逐渐变慢。如何分析解决

当MySQL崩溃并恢复时，它会遍历所有打开的ibd文件的标题页来检查数据字典的准确性。如果MySQL包含大量表，这个验证过程会更加耗时。 MySQL下的崩溃恢复其实和表的数量有关。表总数越大，崩溃恢复时间越长。此外，磁盘IOPS也会影响崩溃恢复时间。例如，这里的开发库硬盘IOPS较低，因此在表空间数量较多的情况下，检查速度非常慢。另一个发现是，表空间检查实际上是在MySQL 8正常启用时进行的，当错误恢复时，会进行额外的表空间检查，相当于检查两次。不过MySQL 8.0还有一个额外的功能，就是当表数量超过5W时，将会启用多线程扫描，以加快表空间验证过程。

如何在 MySQL 5.7 中跳过验证？有没有办法在崩溃恢复期间跳过表空间验证过程？查了资料，主要有两种方法：

1。配置 innodb_force_recovery 以便 srv_force_recovery != 0 然后 validate = false 这意味着您可以跳过表空间验证。实际测试时，设置innodb_force_recovery =1，表示强制recovery跳过坏页，可以跳过检查然后重启即可正常启动。这种临时方法可以避免崩溃恢复后非常耗时的检查表空间的过程，并快速启动MySQL。目前我还没有发现任何隐患。 2. 使用共享表空间而不是独立表空间。这样你就不必打开N个ibd文件。只需要打开一个ibdata文件，大大节省了验证时间。听了姜老师讲了使用共享表空间而不是独立表空间来应对删除大表时的性能波动的原理后，我相信共享表空间在很多业务环境中更有优势。

临时想到了另一个解决思路，就是使用GDB来调试崩溃恢复。暂时改变check变量的值可能会导致MySQL跳过表空间检查过程，然后让MySQL正常关闭并重新启动。然而，实际测试发现，如果在调试模式下运行，实际上可以临时更改验证变量并跳过表空间验证过程。然而，调试模式下的代码执行会大大减少并且需要更长的时间。当在非调试模式下运行时，验证变量无法更改，这个想法就被打破了。

如何解决外网访问mysql数据库慢的问题

在局域网中安装服务器进行测试时，数据库访问速度还是很高的。但当服务器安装在外网时，数据库访问速度就变得非常慢。

后来在网上找到了解决方案，在my.ini中添加了

[mysqld]

skip-name-resolve

。这样会更快！

skip-name-resolve

选项 您可以禁用 DNS 解析，连接速度会更快。但是，在这种情况下，MySQL 授权表中不能使用主机名，只能使用 ip 格式。

至于MySQL本身，问题出在mysql dns反解析

mysqlshow processlist;

| 20681949 |未经授权的用户 | 4.10.193:52497 |空 |连接 | |网络阅读 |空 |

| 20681948 |未经授权的用户 | 4.10.193:52495 |空 |连接 |这会导致系统非常慢。

查看mysql官方网站时，发现这是官方系统中的一个特殊设置。我们就将其视为 mysql 错误。无论哪种连接方式，都是通过主机或IP方式。它将更改 DNS。进行复核。 mysqld 将尝试反向 IP-dns。由于检查解析太慢，它无法应对过多的查询。

MySQL 数据库服务器的速度逐渐变慢。如何分析解决

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

第一个方向是MySQL内部观察

第二个方向是外部来源观察

第三个方向是外部需求转化

1.1 MySQL内部观察

我们来看看MySQL内部观察。常用的观察方法如下。从上到下看，第一部分是Process List，看哪个SQL压力不正常，第二步是解释，解释它的执行计划，第三步是进行profiling，如果SQL可以再次执行，则做Profiling ，那么更高的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 告诉我们虚拟内存的状态、分页是否存在问题以及是否使用分页。

4。 mpstat -P ALL 告诉我们每个核心的 CPU 压力是否均匀。

5.pidstat 1 告诉我们每个进程的资源消耗情况如何。

我们看最后五项：

第一个是iostat -xz 1检查IO问题，然后free-m内存使用情况，然后两个sar根据设备网卡维度检查网络。消费状态以及总体 TCP 使用情况和错误率。最后一个命令 top 查看一般进程和线程问题。

这是外部来源的诊断。这十个命令揭示了需要诊断哪些外部源。

1.3 外部需求的转变

第三个诊断思路是外部需求的转变。我在这里引用该文件。本文档是MySQL官方文档中的一个章节。本章称为“常见查询示例”，文档介绍了如何编写常见 SQL 并给出了一些示例。该文章的链接位于幻灯片上。

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

从表中选择。该表具有三列：商品、商家和价格。它选择每个作者最昂贵的产品并将它们放入结果集中。这是他最原始的SQL。和业务写法很一致，不过是相关子查询。

相关子查询的开销非常大，所以上面的文档将教你如何快速将其转换为非相关子查询。可以看到中间子查询和外层查询没有关联。 。

第三步将教你如何直接去掉子查询，然后将其转换为这样的SQL。这就是所谓的业务转型。前后3条SQL的成本是不同的。删除关联子查询的成本是删除后，SQL 可以正常工作，但该 SQL 无法再被很好地定义。仅当发现 SQL 开销较高时才建议使用此方法。

为什么它会破坏相关子查询？

这背后的原理是关系代数。所有 SQL 都可以表示为等效的关系代数表达式。关系代数表达式之间存在等价性。这种等价关系可以通过转换来分解关联的子查询。

上面的文档是一本大学教科书，从一开始就讲代数和SQL之间的关系。然后一步步弄清楚如何简化这个SQL语句。

首先，MySQL本身提供了很多命令来观察MySQL本身的各种状态。一般来说，通过从上到下的检查就可以检测出SQL或者服务器的问题。

其次，从服务器角度，我们从检查脚本的角度出发。服务器资源只有这几种，观察方法也只有几种。我们只能观察所有服务器资源。

第三，如果实在想不出来，查询者需要把SQL写成数据库容易接受的方式。这个成本会下降得很快。这是 MySQL 缓慢的常见诊断思路。