mysql 查询速度慢仅仅不到 3000 条数据 3.8 秒

这个得上查询分析结果，explain 一下

@mikeguan 执行计划

表重建一下，我司把图片的二进制编码也存在 mysql 里，导致查询巨慢，我是第一次看到这么玩

@dog82 怎么 重建啊 我存的地址 啊

一般来说,选择所有也不存在说为查询时间,这个时间包括了网络传输时间(不太确定),我看你这表字段挺多的,可能是记录太大了传的慢.不然你试一下 select id from table?

@Vegetable select id 挺快的 ，实际业务 也没有 select * 的 但是 我就是 试了一下 感觉查询时间 太长了 不知道 啥问题 ，带宽目前是 5M 的 不知道有关系没

你这是因为数据量太大了，基本都是网络传输的时间，你切换到 概况 一栏，像可以看具体的时间。

type: ALL 就说明走了全表扫描，没有用到索引。

查所有记录和大的分段查询都很慢，尽量避免吧。像 Redis 的 keys *都有可能直接搞挂服务

type：ALL，没有索引；但是没索引也不至于这么慢，看看网络和磁盘 IO

我遇到过。和五楼观点一样。每一行的表字段太多，**从磁盘加载到内存太耗时间了**，如果仅查询 select id 那肯定不一样。不是查询慢，是磁盘到内存慢。我之前写过一篇博客，楼主可以看看。https://www.cnblogs.com/wenbochang/p/10257416.html 。

对接过 14s 的接口，手动狗头

首先,不要用 *
其次,我说完了.

* 换成具体列，或者把表拆分。

一行数据多大?

究竟多少字段，多少数据，你敢把查询结果导出一份.sql 看看大小吗

@CallMeReznov #13
@himesens #14
我之前看一篇 blog，不是说新的 MySQL 用*和指定全列效率差不多嘛

网络原因吧,3000 条数据,本地写个 txt 文件再读也不至于 4 秒

@javen73 的确,但是读取多余数据会浪费时间,上边说把二进制存数据库的就是,单条纪录太大了,查得是不慢,传的慢.

没走索引...

记录值太大，可能存了长文本或者图片，导致页分裂了，再加上网速不行 fetch 的时候自然就慢了

工具的这个时间可能包括了网络 IO。 建议你到数据库所在的机器上进行查询。3000 条数据查询全表也不可能达到秒级别的

倾向于网络传输时间长了，一下查询三千条数据，传输肯定要时间，按上边说的点开概况看看，是不是 sending data 用时最长。。。

CPU,IO,网络 一般就这三点

这个 4 秒包含网络传输吧，用 heidisql 查下，能看到查询和传输单独用了多久 https://imgur.com/Ggp4Rhg

@harvies

有主键吗........

```
SELECT * FROM tagert_table AS t1 INNER JOIN (SELECT id FROM target_table WHERE category_id = 15) AS t2 USING (`id`)
```

可以满足？

直接 mysql 命令模式连接 127.0.0.1 试试，然后不要用*。
用一些可视化工具，如果每一条的数据太多了，把数据绘制到表格里面会巨慢。

楼上说不要用*的基本都是半吊子水平，实际上在没有索引的情况下，select * 和 select `field` 效率差不多

没有命中索引哦

@javen73 不到 3000 条数据 和 * 不* 的没关系 我始终这么觉得

@awanabe select * 走 什么索引

@Aresxue 谢谢 老哥 确实 存在这么个情况

@golden0125 谢谢 老哥

@bzj 是的 实现过 况且 不到 3000 条数据 * 不* 的确实没关系

那两个查询参数的索引加上了吗。
照理说不应该啊，才 3000 条数据

和 * 没关系。。 * 在运行之前会自动解析成字段的。
你这个首先 索引没上。其次返回了 2000 多条数据 这个数据传输上应该不小

查询之后可以先看看剖析，看一下是那个步骤耗时最多。我截图中就是 sending data 的动作耗时最多，占了 65%

@571726193 #33 你是执行了你选择的 sql 么..后面没有 where 么

如果是这样...当我没说哈哈

这是 mysql workbench 辣鸡而已，莫慌....我也遇到过你这个情况
workbench 逆天用时，然后用 sequel 执行了下很正常。

mac 上数据库工具使用感受：
workbench：敲 sql 时能实时报错，但是 select 不稳，有时莫名逆天慢
sequel：select 执行的稳，但是写 sql 的提示是真的不顺手
navicat：提示立马就出来，写 sql 特别顺，执行起来也相对稳，有时候 stop query 时会导致程序未响应...只能强关

现在基本在用 sequel，因为他用起来稳定...不会莫名奇妙逆天慢

@519718366 我从 Sequel Pro 换到了 TablePlus

@HowardTang
对接过 2 分钟的接口，用的是 Chunked transfer encoding。每一个 chunk 的速度都是秒级=.=

*不*影响网络传输时间....取一列数据量少....

查询条件是 varchar ？还是 int，遇到过 varchar 然后没加引号很慢的情况

（ 1 ）只查询需要的字段
（ 2 ）对查询字段建立索引

每行数据是不是很大啊？ 3000 条就算没索引没不至于这么慢

2H4G 机房 1000M 宽带内网（可能更高），一直都没怎么在乎过性能问题.....

大家没注意到他的图下方的滑动条吗 看似每行的列字段好多

肯定是字段很大，下载时间很长

1. explain 说的是 all，扫全表。
2. 你查的结果是 3k 条，但是得到这 3k 条的过程是扫描了全表的，即使前 3k 条就是你要的数据了，sql 还是会扫描完，因为 sql 不知道。
3. 联合索引有没有用上。
4. 可能有大量的随机 IO。

@panlatent 我去体验一波，没准会被你这个 tableplus 给大一统了