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

答:这个得上查询分析结果，explain 一下
答:表重建一下，我司把图片的二进制编码也存在 mysql 里，导致查询巨慢，我是第一次看到这么玩
答:一般来说,选择所有也不存在说为查询时间,这个时间包括了网络传输时间(不太确定),我看你这表字段挺多的,可能是记录太大了传的慢.不然你试一下 select id from table?
答:你这是因为数据量太大了，基本都是网络传输的时间，你切换到 概况 一栏，好像可以看具体的时间。
答:type: ALL 就说明走了全表扫描，没有用到索引。
答:查所有记录和大的分段查询都很慢，尽量避免吧。像 Redis 的 keys *都有可能直接搞挂服务
答:type：ALL，没有索引；但是没索引也不至于这么慢，看看网络和磁盘 IO
答:我遇到过。和五楼观点一样。每一行的表字段太多，**从磁盘加载到内存太耗时间了**，如果仅查询 select id 那肯定不一样。不是查询慢，是磁盘到内存慢。我之前写过一篇博客，楼主可以看看。https://www.cnblogs.com/wenbochang/p/10257416.html 。
答:对接过 14s 的接口，手动狗头
答:首先,不要用 *
其次,我说完了.
答:* 换成具体列，或者把表拆分。
答:一行数据多大?
答:究竟多少字段，多少数据，你敢把查询结果导出一份.sql 看看大小吗
答:网络原因吧,3000 条数据,本地写个 txt 文件再读也不至于 4 秒
答:没走索引...
答:记录值太大，可能存了长文本或者图片，导致页分裂了，再加上网速不行 fetch 的时候自然就慢了
答:工具的这个时间可能包括了网络 IO。 建议你到数据库所在的机器上进行查询。3000 条数据查询全表也不可能达到秒级别的
答:倾向于网络传输时间长了，一下查询三千条数据，传输肯定要时间，按上边说的点开概况看看，是不是 sending data 用时最长。。。
答:CPU,IO,网络 一般就这三点
答:这个 4 秒包含网络传输吧，用 heidisql 查下，能看到查询和传输单独用了多久 https://imgur.com/Ggp4Rhg
答:有主键吗........
答:```
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` 效率差不多
答:没有命中索引哦
答:那两个查询参数的索引加上了吗。
照理说不应该啊，才 3000 条数据
答:和 * 没关系。。 * 在运行之前会自动解析成字段的。
你这个首先 索引没上。其次返回了 2000 多条数据 这个数据传输上应该不小
答:
查询之后可以先看看剖析，看一下是那个步骤耗时最多。我截图中就是 sending data 的动作耗时最多，占了 65%
答:这是 mysql workbench 辣鸡而已，莫慌....我也遇到过你这个情况
workbench 逆天用时，然后用 sequel 执行了下很正常。

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

现在基本在用 sequel，因为他用起来稳定...不会莫名奇妙逆天慢
答:*不*影响网络传输时间....取一列数据量少....
答:查询条件是 varchar ？还是 int，遇到过 varchar 然后没加引号很慢的情况
答:（ 1 ）只查询需要的字段
（ 2 ）对查询字段建立索引
答:每行数据是不是很大啊？ 3000 条就算没索引没不至于这么慢
答:2H4G 机房 1000M 宽带内网（可能更高），一直都没怎么在乎过性能问题.....