Mysql查询很慢卡在sending data的原因及解决思路讲解
因为编写了一个Python程序，密集的操作了一个Mysql库，之前数据量不大时，没发现很慢，后来越来越慢，以为只是数据量大了的原因，但是后来慢到不能忍受了，查了半天，索引能用的都用上了，执行一次还是要3到4秒，不能忍受了。
于是把一些可以缓存的查询全部用redis缓存了起来，大大加速了应用。
但是还是有一些没办法缓存的，或者说，每次查询都是不一样的结果的就没办法了。用navicat的查询概况可以看到卡住的地方是在：Sending data一段，用时3.5秒，占了99%的查询时间。
在网上查了一些，有些是因为sql语句的问题，但是我这个完全没有用到varchar，也没用到in方法。
于是想是不是表太大了，可能没有缓存到内存中，于是先查mysqld进程占的内存，才50多M，明显太少了，那张表的实际容量有200多M,这个可以在navicat的对象一栏看到，应该是每次查都是从磁盘读取，所以很耗费时间，于是查看win10的磁盘IO,发现确实是这样，磁盘IO达到了100%，还是固态硬盘，每秒读取80M左右，难怪这么慢了。
于是查了mysql的配置文件，发现有一项配置才32M,调成512M,重启mysql，搞定这次从3.5秒变成了0.76秒了。
配置项是：
innodb_buffer_pool_size=32M
这是mysql5.7默认的，改成512或1024，再重启即可，看你的硬件配置。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对小牛知识库的支持。如果你想了解更多相关内容请查看下面相关链接
-
主要内容：前言,查询慢深层次原因揭秘：磁盘IO的过程,磁盘的顺序读写和随机读写,磁盘IO到底会有多慢呢？,用户查询请求慢的根本原因前言 接上一节，那么，一次查询的全过程是什么样的呢？ 这个时候，我们通过各种百度和Google，然后加上自己的理解，终于搞明白了MySQL一次查询的全过程了。 首先，用户想要查询订单数据时，会先发送一个查询请求，如下图所示： 可以看到，当用户发送查询请求时，因为外卖订单项目是部署在Tomcat中的，Tomcat中的线程首先就会接收到用户的请求，然后把请求交给外卖订单项
-
本文向大家介绍Vue-cropper 图片裁剪的基本原理及思路讲解，包括了Vue-cropper 图片裁剪的基本原理及思路讲解的使用技巧和注意事项，需要的朋友参考一下 一：裁剪的思路： 1-1，裁剪区域：需要进行裁剪首先需要形成裁剪区域，裁剪区域的大小和我们的鼠标移动的距离相关联，鼠标移动有多远，裁剪区域就有多大。如下图： 1-2 裁剪区域的宽和高的计算： 如上图，鼠标的横向移动距离和纵向移动距离
-
问题内容： 我有一个大约有110.000.000项的大型mysql表 表设计为： 现在我要查询一个普通查询： Explain语句给我： 该查询似乎很慢（约185秒），但我不知道这是否仅是由于表中的项目数量所致。您是否提示我如何加快查询或查表的速度？ 问题答案： 我通常都同意Drap，但是以下查询变体可能更加有效，尤其是对于更大的LIMIT： 要求和索引。
-
本文向大家介绍分享ThinkPHP3.2中关联查询解决思路，包括了分享ThinkPHP3.2中关联查询解决思路的使用技巧和注意事项，需要的朋友参考一下 不废话了，直接给大家贴代码了，代码很简单，都是比较常见的sql语句，具体内容请看下文。 如上三个表：用户头像表、产品表、用户表 怎样在模型中建立关联？ 试过用HAS_ONE、BELONGS_TO、HAS_MANY、MANY_TO_MANY都不行，求
-
本文向大家介绍Mysql慢查询优化方法及优化原则，包括了Mysql慢查询优化方法及优化原则的使用技巧和注意事项，需要的朋友参考一下 1、日期大小的比较，传到xml中的日期格式要符合'yyyy-MM-dd'，这样才能走索引，如：'yyyy'改为'yyyy-MM-dd'，'yyyy-MM'改为'yyyy-MM-dd'【这样MYSQL会转换为日期类型】 2、条件语句中无论是等于、还是大于小于，WHERE
-
本文向大家介绍sqoop export导出 map100% reduce0% 卡住的多种原因及解决，包括了sqoop export导出 map100% reduce0% 卡住的多种原因及解决的使用技巧和注意事项，需要的朋友参考一下 我称这种bug是一个典型的“哈姆雷特”bug，就是指那种“报错情况相同但网上却会有各种五花缭乱解决办法”的bug，让我们不知道哪一个才是症结所在。 先看导入命令： 这个