1
mikeguan 2019-09-27 09:48:42 +08:00 via Android
这个得上查询分析结果,explain 一下
|
2
571726193 OP |
3
dog82 2019-09-27 09:52:45 +08:00
表重建一下,我司把图片的二进制编码也存在 mysql 里,导致查询巨慢,我是第一次看到这么玩
|
5
Vegetable 2019-09-27 09:56:36 +08:00
一般来说,选择所有也不存在说为查询时间,这个时间包括了网络传输时间(不太确定),我看你这表字段挺多的,可能是记录太大了传的慢.不然你试一下 select id from table?
|
6
571726193 OP @Vegetable select id 挺快的 ,实际业务 也没有 select * 的 但是 我就是 试了一下 感觉查询时间 太长了 不知道 啥问题 ,带宽目前是 5M 的 不知道有关系没
|
7
arrow8899 2019-09-27 09:59:21 +08:00
你这是因为数据量太大了,基本都是网络传输的时间,你切换到 概况 一栏,好像可以看具体的时间。
|
8
awker 2019-09-27 10:02:19 +08:00
type: ALL 就说明走了全表扫描,没有用到索引。
|
9
mikeguan 2019-09-27 10:02:36 +08:00 via Android
查所有记录和大的分段查询都很慢,尽量避免吧。像 Redis 的 keys *都有可能直接搞挂服务
|
10
b821025551b 2019-09-27 10:04:10 +08:00
type:ALL,没有索引;但是没索引也不至于这么慢,看看网络和磁盘 IO
|
11
bigbigeggs 2019-09-27 10:09:07 +08:00
我遇到过。和五楼观点一样。每一行的表字段太多,**从磁盘加载到内存太耗时间了**,如果仅查询 select id 那肯定不一样。不是查询慢,是磁盘到内存慢。我之前写过一篇博客,楼主可以看看。https://www.cnblogs.com/wenbochang/p/10257416.html 。
|
12
HowardTang 2019-09-27 10:47:08 +08:00
对接过 14s 的接口,手动狗头
|
13
CallMeReznov 2019-09-27 10:49:21 +08:00
首先,不要用 *
其次,我说完了. |
14
himesens 2019-09-27 10:50:54 +08:00
* 换成具体列,或者把表拆分。
|
15
Raymon111111 2019-09-27 10:53:18 +08:00
一行数据多大?
|
16
TanLeDeDaNong 2019-09-27 10:54:11 +08:00
究竟多少字段,多少数据,你敢把查询结果导出一份.sql 看看大小吗
|
17
javen73 2019-09-27 10:54:35 +08:00
|
18
qq976739120 2019-09-27 11:02:01 +08:00 1
网络原因吧,3000 条数据,本地写个 txt 文件再读也不至于 4 秒
|
20
awanabe 2019-09-27 11:09:52 +08:00
没走索引...
|
21
Aresxue 2019-09-27 11:12:54 +08:00
记录值太大,可能存了长文本或者图片,导致页分裂了,再加上网速不行 fetch 的时候自然就慢了
|
22
zdt3476 2019-09-27 11:16:24 +08:00
工具的这个时间可能包括了网络 IO。 建议你到数据库所在的机器上进行查询。3000 条数据查询全表也不可能达到秒级别的
|
23
jay4497 2019-09-27 11:21:38 +08:00
倾向于网络传输时间长了,一下查询三千条数据,传输肯定要时间,按上边说的点开概况看看,是不是 sending data 用时最长。。。
|
24
golden0125 2019-09-27 11:28:47 +08:00
CPU,IO,网络 一般就这三点
|
25
harvies 2019-09-27 13:10:59 +08:00
这个 4 秒包含网络传输吧,用 heidisql 查下,能看到查询和传输单独用了多久 https://imgur.com/Ggp4Rhg
|
27
tonic 2019-09-27 13:35:59 +08:00
有主键吗........
|
28
gemini767 2019-09-27 13:39:37 +08:00
```
SELECT * FROM tagert_table AS t1 INNER JOIN (SELECT id FROM target_table WHERE category_id = 15) AS t2 USING (`id`) ``` 可以满足? |
29
5200 2019-09-27 13:46:42 +08:00
直接 mysql 命令模式连接 127.0.0.1 试试,然后不要用*。
用一些可视化工具,如果每一条的数据太多了,把数据绘制到表格里面会巨慢。 |
30
bzj 2019-09-27 14:00:22 +08:00
楼上说不要用*的基本都是半吊子水平,实际上在没有索引的情况下,select * 和 select `field` 效率差不多
|
31
zhuzhibin 2019-09-27 14:00:25 +08:00 via iPhone
没有命中索引哦
|
35
571726193 OP @golden0125 谢谢 老哥
|
37
haishiwuyuehao 2019-09-27 14:53:33 +08:00
那两个查询参数的索引加上了吗。
照理说不应该啊,才 3000 条数据 |
38
kobayashiro 2019-09-27 15:54:17 +08:00
和 * 没关系。。 * 在运行之前会自动解析成字段的。
你这个首先 索引没上。其次返回了 2000 多条数据 这个数据传输上应该不小 |
39
Egfly 2019-09-27 15:56:45 +08:00
![navicat 剖析]( https://cdn.learnku.com/uploads/images/201909/27/33663/cwUC7cv2O7.png!/fw/1240)
查询之后可以先看看剖析,看一下是那个步骤耗时最多。我截图中就是 sending data 的动作耗时最多,占了 65% |
41
519718366 2019-09-27 17:56:00 +08:00
这是 mysql workbench 辣鸡而已,莫慌....我也遇到过你这个情况
workbench 逆天用时,然后用 sequel 执行了下很正常。 mac 上数据库工具使用感受: workbench:敲 sql 时能实时报错,但是 select 不稳,有时莫名逆天慢 sequel:select 执行的稳,但是写 sql 的提示是真的不顺手 navicat:提示立马就出来,写 sql 特别顺,执行起来也相对稳,有时候 stop query 时会导致程序未响应...只能强关 现在基本在用 sequel,因为他用起来稳定...不会莫名奇妙逆天慢 |
43
Macolor21 2019-09-27 21:36:05 +08:00
@HowardTang
对接过 2 分钟的接口,用的是 Chunked transfer encoding。每一个 chunk 的速度都是秒级=.= |
44
cz5424 2019-09-27 21:50:49 +08:00 via iPhone
*不*影响网络传输时间....取一列数据量少....
|
45
zrc 2019-09-27 22:01:49 +08:00 1
查询条件是 varchar ?还是 int,遇到过 varchar 然后没加引号很慢的情况
|
46
feiffy 2019-09-27 22:12:05 +08:00
( 1 )只查询需要的字段
( 2 )对查询字段建立索引 |
47
iluckypig 2019-09-27 22:12:44 +08:00
每行数据是不是很大啊? 3000 条就算没索引没不至于这么慢
|
48
skyqqcc 2019-09-28 02:21:11 +08:00 via Android
2H4G 机房 1000M 宽带内网(可能更高),一直都没怎么在乎过性能问题.....😂
|
49
xiaodim 2019-09-28 09:28:28 +08:00
大家没注意到他的图下方的滑动条吗 看似每行的列字段好多
|
50
tailf 2019-09-28 09:47:22 +08:00
肯定是字段很大,下载时间很长
|
51
LuckCode 2019-09-28 11:27:33 +08:00
1. explain 说的是 all,扫全表。
2. 你查的结果是 3k 条,但是得到这 3k 条的过程是扫描了全表的,即使前 3k 条就是你要的数据了,sql 还是会扫描完,因为 sql 不知道。 3. 联合索引有没有用上。 4. 可能有大量的随机 IO。 |