mysql5.7 select* 查询 sendingdata很慢

x379769646 2018-06-21 03:21:46

我有一张40多W数据的秒，select * 查询要40多秒 99%的时间都在sending data ,求解怎么样提高速率

...全文

356 3 打赏收藏转发到动态举报

写回复

3 条回复

切换为时间正序

请发表友善的回复…

发表回复

mynamexuerui 2018-06-21

打赏
举报

回复

不是说提升硬件是万能的方法吗？？？

x379769646 2018-06-21

打赏
举报

回复

求解

丰云 2018-06-21

打赏
举报

回复

这种问题完全没有回答的欲望。。。。。
是托吗。。。

最近在代码优化中，发现了一条sql语句非常的慢，于是就用各种方法进行排查，最后终于找到了原因。一、事故现场SELECT og.goods_barcode, og.color_id, og.size_id, SUM(og.goods_number) AS sold_number FROM order oLEFT JOIN order_goods og ON o.order_id = og.order...

在执行一个简单的sql查询,表中数据量为14万sql语句为：SELECT id,titile,published_at from spider_36kr_record where is_analyze=0 ORDER BY create_time DESC LIMIT 10;开始的时候很快，但后面sql语句查询越来越慢。开始查找问题原因；1. 执行explain发现没毛病，正常走了索引2. 执...

既然每次从驱动表取数据比较耗时，那我们每次从驱动表取一批数据放到内存中，然后对这一批数据进行匹配操作。这批数据匹配完毕，再从驱动表中取一批数据放到内存中，直到驱动表的数据全都匹配完毕批量取数据能减少很多IO操作，因此执行效率比较高，这种连接操作也被MySQL采用对了，这块内存在MySQ中有一个专有的名词，叫做 join buffer，我们可以执行如下语句查看 join buffer 的大小。

简单解读，数据查询和执行通常只需要不到0.01秒，而网络输出通常需要1秒左右甚至更长，原本数据连接在0.01秒即可释放，但是因为前端程序未执行close操作，直接输出结果，那么在结果未展现在用户桌面前，该数据库连接一直维持在sleep状态！如果大量出现，内存，硬盘可能已经出现问题，比如硬盘满或损坏，或者执行正在进行清理更新日志索引等，i/o压力过大时，也可能出现Free items执行时间较长的情况。很可怕的搜索语句会导致这样的情况，如果是数据分析，或者半夜的周期数据清理任务，偶尔出现，可以允许。

遇到故障，我们往往想的是如何解决这个故障，而不是从故障的根本去思考出现这个故障的原因？这样的结果，只能使我们得到了鱼，失去了渔。今天，我们就来分享一个由USE DB堵塞故障引发的思考案例。故障描述今天一个朋友遇到数据库遇到一个严重的故障，故障环境如下：MYSQL 5.6.16RR隔离级别GITD关闭表现如下：use db不能进入数据库show table status不能查询到表信息schema....

22,298

社区成员

121,733

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章