This topic created in 2596 days ago, the information mentioned may be changed or developed.
 |
mikeguanSep 27, 2019 via Android
1
这个得上查询分析结果，explain 一下
|
 |
2
|
 |
dog82Sep 27, 2019
3
表重建一下，我司把图片的二进制编码也存在 mysql 里，导致查询巨慢，我是第一次看到这么玩
|
 |
VegetableSep 27, 2019
5
一般来说,选择所有也不存在说为查询时间,这个时间包括了网络传输时间(不太确定),我看你这表字段挺多的,可能是记录太大了传的慢.不然你试一下 select id from table?
|
|
6
@Vegetable select id 挺快的 ，实际业务 也没有 select * 的 但是 我就是 试了一下 感觉查询时间 太长了 不知道 啥问题 ，带宽目前是 5M 的 不知道有关系没
|
 |
arrow8899Sep 27, 2019
7
你这是因为数据量太大了，基本都是网络传输的时间，你切换到 概况 一栏，好像可以看具体的时间。
|
 |
awkerSep 27, 2019
8
type: ALL 就说明走了全表扫描，没有用到索引。
|
|
mikeguanSep 27, 2019 via Android
9
查所有记录和大的分段查询都很慢，尽量避免吧。像 Redis 的 keys *都有可能直接搞挂服务
|
 |
b821025551bSep 27, 2019
10
type：ALL，没有索引；但是没索引也不至于这么慢，看看网络和磁盘 IO
|
 |
bigbigeggsSep 27, 2019
11
我遇到过。和五楼观点一样。每一行的表字段太多，**从磁盘加载到内存太耗时间了**，如果仅查询 select id 那肯定不一样。不是查询慢，是磁盘到内存慢。我之前写过一篇博客，楼主可以看看。https://www.cnblogs.com/wenbochang/p/10257416.html 。
|
 |
HowardTangSep 27, 2019
12
对接过 14s 的接口，手动狗头
|
 |
CallMeReznovSep 27, 2019
13
首先,不要用 *
其次,我说完了. |
 |
himesensSep 27, 2019
14
* 换成具体列，或者把表拆分。
|
 |
Raymon111111Sep 27, 2019
15
一行数据多大?
|
 |
TanLeDeDaNongSep 27, 2019
16
究竟多少字段，多少数据，你敢把查询结果导出一份.sql 看看大小吗
|
 |
javen73Sep 27, 2019
17
|
 |
18
网络原因吧,3000 条数据,本地写个 txt 文件再读也不至于 4 秒
|
1 |
awanabeSep 27, 2019
20
没走索引...
|
 |
AresxueSep 27, 2019
21
记录值太大，可能存了长文本或者图片，导致页分裂了，再加上网速不行 fetch 的时候自然就慢了
|
 |
zdt3476Sep 27, 2019
22
工具的这个时间可能包括了网络 IO。 建议你到数据库所在的机器上进行查询。3000 条数据查询全表也不可能达到秒级别的
|
 |
jay4497Sep 27, 2019
23
倾向于网络传输时间长了，一下查询三千条数据，传输肯定要时间，按上边说的点开概况看看，是不是 sending data 用时最长。。。
|
 |
golden0125Sep 27, 2019
24
CPU,IO,网络 一般就这三点
|
 |
harviesSep 27, 2019
25
这个 4 秒包含网络传输吧，用 heidisql 查下，能看到查询和传输单独用了多久 https://imgur.com/Ggp4Rhg
|
 |
tonicSep 27, 2019
27
有主键吗........
|
 |
gemini767Sep 27, 2019
28
```
SELECT * FROM tagert_table AS t1 INNER JOIN (SELECT id FROM target_table WHERE category_id = 15) AS t2 USING (`id`) ``` 可以满足？ |
 |
5200Sep 27, 2019
29
直接 mysql 命令模式连接 127.0.0.1 试试，然后不要用*。
用一些可视化工具，如果每一条的数据太多了，把数据绘制到表格里面会巨慢。 |
 |
bzjSep 27, 2019
30
楼上说不要用*的基本都是半吊子水平，实际上在没有索引的情况下，select * 和 select `field` 效率差不多
|
 |
zhuzhibinSep 27, 2019 via iPhone
31
没有命中索引哦
|
|
35
@golden0125 谢谢 老哥
|
 |
haishiwuyuehaoSep 27, 2019
37
那两个查询参数的索引加上了吗。
照理说不应该啊，才 3000 条数据 |
 |
kobayashiroSep 27, 2019
38
和 * 没关系。。 * 在运行之前会自动解析成字段的。
你这个首先 索引没上。其次返回了 2000 多条数据 这个数据传输上应该不小 |
 |
EgflySep 27, 2019
39
查询之后可以先看看剖析，看一下是那个步骤耗时最多。我截图中就是 sending data 的动作耗时最多，占了 65% |
 |
519718366Sep 27, 2019
41
这是 mysql workbench 辣鸡而已，莫慌....我也遇到过你这个情况
workbench 逆天用时，然后用 sequel 执行了下很正常。 mac 上数据库工具使用感受： workbench：敲 sql 时能实时报错，但是 select 不稳，有时莫名逆天慢 sequel：select 执行的稳，但是写 sql 的提示是真的不顺手 navicat：提示立马就出来，写 sql 特别顺，执行起来也相对稳，有时候 stop query 时会导致程序未响应...只能强关 现在基本在用 sequel，因为他用起来稳定...不会莫名奇妙逆天慢 |
 |
Macolor21Sep 27, 2019
43
@HowardTang
对接过 2 分钟的接口，用的是 Chunked transfer encoding。每一个 chunk 的速度都是秒级=.= |
 |
cz5424Sep 27, 2019 via iPhone
44
*不*影响网络传输时间....取一列数据量少....
|
 |
45
查询条件是 varchar ？还是 int，遇到过 varchar 然后没加引号很慢的情况
|
 |
feiffySep 27, 2019
46
（ 1 ）只查询需要的字段
（ 2 ）对查询字段建立索引 |
 |
iluckypigSep 27, 2019
47
每行数据是不是很大啊？ 3000 条就算没索引没不至于这么慢
|
 |
skyqqccSep 28, 2019 via Android
48
2H4G 机房 1000M 宽带内网（可能更高），一直都没怎么在乎过性能问题.....😂
|
 |
xiaodimSep 28, 2019
49
大家没注意到他的图下方的滑动条吗 看似每行的列字段好多
|
 |
tailfSep 28, 2019
50
肯定是字段很大，下载时间很长
|
 |
LuckCodeSep 28, 2019
51
1. explain 说的是 all，扫全表。
2. 你查的结果是 3k 条，但是得到这 3k 条的过程是扫描了全表的，即使前 3k 条就是你要的数据了，sql 还是会扫描完，因为 sql 不知道。 3. 联合索引有没有用上。 4. 可能有大量的随机 IO。 |
Select Language