一、mysql 慢查询 会影响其他查询吗

肯定影响的。

常见查询慢的原因常见的话会有如下几种：

1、没有索引或没有用到索引。

PS：索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个*作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。

索引类型：

普通索引：这是基本的索引类型，没唯一性之类的限制。

唯一性索引：和普通索引基本相同，但所有的索引列只能出现一次，保持唯一性。

主键：主键是一种唯一索引，但必须指定为"PRIMARY KEY"。

全文索引：MYSQL从3.23.23开始支持全文索引和全文检索。在MYSQL中，全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。

2、IO吞吐量小形成了瓶颈。

PS：这是从系统层来分析MYSQL是比较耗IO的。一般数据库监控也是比较关注IO。

监控命令：$iostat-d-k 1 10

参数-d表示，显示设备（磁盘）使用状态；-k某些使用block为单位的列强制使用Kilobytes为单位；1 10表示，数据显示每隔1秒刷新一次，共显示10次。

3、内存不足

监控内存使用：vmstat [-n] [延时[次数]]

Memory

swpd:切换到交换内存上的内存(默认以KB为单位)

•如果 swpd的值不为0，或者还比较大，比如超过100M了，但是si, so的值长期为0，这种情况我们可以不用担心，不会影响系统性能。

free:空闲的物理内存

buff:作为buffer cache的内存，对块设备的读写进行缓冲

cache:作为page cache的内存,文件系统的cache•如果 cache的值大的时候，说明cache住的文件数多，如果频繁访问到的文件都能被cache住，那么磁盘的读IO **会非常小。

4、网络速度慢

ping IP-t查看是否有丢包。

5、一次查询的数据量过大。

比如没有分页查询，一次提取上万条记录。数据库有可能卡死。

6、出现死锁

所谓死锁:是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.

Show innodb status检查引擎状态,可以看到哪些语句产生死锁。

执行show processlist找到死锁线程号.然后KillprocessNo

7、返回了不必要的行或列

一般查询SQL语句一定要将字段明确指定。而不要使用*进行查询

8、注意UNion和UNion all的区别。UNION all好

UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。所以union all的效率肯定要高！

二、哪些因素影响了数据库性能

网络宽带，磁盘IO，查询速度都会影响到数据库的性能。

具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。

为什么当磁盘IO成瓶颈之后,数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？

相信大部分做数据库运维的朋友，都遇到这种情况。数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个简单的insert*作，需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？

dba此时心中有无限的疑惑，到底是什么原因呢?磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？还是数据库内部出问题？昨天不是还好好的吗？

当数据库出现响应时间不稳定的时候，我们在*作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO.数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于**交易的数据库系统来说，大概性能就雪崩了。为什么*作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？

如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。

在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。

咱们先来提问题。buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。

提问.数据页不在buffer bool里面该怎么办？

回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool,图片中显示

buffer_read_page函数栈的顶层是pread64(),调用了*作系统的读函数。

buf_read_page的代码

如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的*作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer中，无法直接使用该数据页，必须等待*作系统完成IO.

再接着上面的回答提问：

当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。

试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool,这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。

通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。

再继续扩展问题：如果会话线程A经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。

由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列后的会话线程后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。

再回头来看上面的问题，mysql数据库出现性能下降时，可以看到*作系统有读IO。原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写*作是不堵塞执行sql的会话线程的。所以，即使看到*作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size,基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在*作系统上基本看不到读的IO。当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool,则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。

三、频繁查询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变量，想法破灭。