V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
571726193
V2EX  ›  Java

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

  •  
  •   571726193 · 2019-09-27 09:46:17 +08:00 · 11963 次点击
    这是一个创建于 1644 天前的主题,其中的信息可能已经有所发展或是发生改变。

    在这里插入图片描述

    52 条回复    2019-10-11 10:04:12 +08:00
    mikeguan
        1
    mikeguan  
       2019-09-27 09:48:42 +08:00 via Android
    这个得上查询分析结果,explain 一下
    571726193
        2
    571726193  
    OP
       2019-09-27 09:52:09 +08:00
    @mikeguan 执行计划
    ![在这里插入图片描述]( https://img-blog.csdnimg.cn/20190927095128931.jpg)
    dog82
        3
    dog82  
       2019-09-27 09:52:45 +08:00
    表重建一下,我司把图片的二进制编码也存在 mysql 里,导致查询巨慢,我是第一次看到这么玩
    571726193
        4
    571726193  
    OP
       2019-09-27 09:53:42 +08:00
    @dog82 怎么 重建啊 我存的地址 啊
    Vegetable
        5
    Vegetable  
       2019-09-27 09:56:36 +08:00
    一般来说,选择所有也不存在说为查询时间,这个时间包括了网络传输时间(不太确定),我看你这表字段挺多的,可能是记录太大了传的慢.不然你试一下 select id from table?
    571726193
        6
    571726193  
    OP
       2019-09-27 09:57:52 +08:00
    @Vegetable select id 挺快的 ,实际业务 也没有 select * 的 但是 我就是 试了一下 感觉查询时间 太长了 不知道 啥问题 ,带宽目前是 5M 的 不知道有关系没
    arrow8899
        7
    arrow8899  
       2019-09-27 09:59:21 +08:00
    你这是因为数据量太大了,基本都是网络传输的时间,你切换到 概况 一栏,好像可以看具体的时间。
    awker
        8
    awker  
       2019-09-27 10:02:19 +08:00
    type: ALL 就说明走了全表扫描,没有用到索引。
    mikeguan
        9
    mikeguan  
       2019-09-27 10:02:36 +08:00 via Android
    查所有记录和大的分段查询都很慢,尽量避免吧。像 Redis 的 keys *都有可能直接搞挂服务
    b821025551b
        10
    b821025551b  
       2019-09-27 10:04:10 +08:00
    type:ALL,没有索引;但是没索引也不至于这么慢,看看网络和磁盘 IO
    bigbigeggs
        11
    bigbigeggs  
       2019-09-27 10:09:07 +08:00
    我遇到过。和五楼观点一样。每一行的表字段太多,**从磁盘加载到内存太耗时间了**,如果仅查询 select id 那肯定不一样。不是查询慢,是磁盘到内存慢。我之前写过一篇博客,楼主可以看看。https://www.cnblogs.com/wenbochang/p/10257416.html
    HowardTang
        12
    HowardTang  
       2019-09-27 10:47:08 +08:00
    对接过 14s 的接口,手动狗头
    CallMeReznov
        13
    CallMeReznov  
       2019-09-27 10:49:21 +08:00
    首先,不要用 *
    其次,我说完了.
    himesens
        14
    himesens  
       2019-09-27 10:50:54 +08:00
    * 换成具体列,或者把表拆分。
    Raymon111111
        15
    Raymon111111  
       2019-09-27 10:53:18 +08:00
    一行数据多大?
    TanLeDeDaNong
        16
    TanLeDeDaNong  
       2019-09-27 10:54:11 +08:00
    究竟多少字段,多少数据,你敢把查询结果导出一份.sql 看看大小吗
    javen73
        17
    javen73  
       2019-09-27 10:54:35 +08:00
    @CallMeReznov #13
    @himesens #14
    我之前看一篇 blog,不是说新的 MySQL 用*和指定全列效率差不多嘛
    qq976739120
        18
    qq976739120  
       2019-09-27 11:02:01 +08:00   ❤️ 1
    网络原因吧,3000 条数据,本地写个 txt 文件再读也不至于 4 秒
    Vegetable
        19
    Vegetable  
       2019-09-27 11:02:49 +08:00
    @javen73 的确,但是读取多余数据会浪费时间,上边说把二进制存数据库的就是,单条纪录太大了,查得是不慢,传的慢.
    awanabe
        20
    awanabe  
       2019-09-27 11:09:52 +08:00
    没走索引...
    Aresxue
        21
    Aresxue  
       2019-09-27 11:12:54 +08:00
    记录值太大,可能存了长文本或者图片,导致页分裂了,再加上网速不行 fetch 的时候自然就慢了
    zdt3476
        22
    zdt3476  
       2019-09-27 11:16:24 +08:00
    工具的这个时间可能包括了网络 IO。 建议你到数据库所在的机器上进行查询。3000 条数据查询全表也不可能达到秒级别的
    jay4497
        23
    jay4497  
       2019-09-27 11:21:38 +08:00
    倾向于网络传输时间长了,一下查询三千条数据,传输肯定要时间,按上边说的点开概况看看,是不是 sending data 用时最长。。。
    golden0125
        24
    golden0125  
       2019-09-27 11:28:47 +08:00
    CPU,IO,网络 一般就这三点
    harvies
        25
    harvies  
       2019-09-27 13:10:59 +08:00
    这个 4 秒包含网络传输吧,用 heidisql 查下,能看到查询和传输单独用了多久 https://imgur.com/Ggp4Rhg
    harvies
        26
    harvies  
       2019-09-27 13:11:53 +08:00
    tonic
        27
    tonic  
       2019-09-27 13:35:59 +08:00
    有主键吗........
    gemini767
        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`)
    ```

    可以满足?
    5200
        29
    5200  
       2019-09-27 13:46:42 +08:00
    直接 mysql 命令模式连接 127.0.0.1 试试,然后不要用*。
    用一些可视化工具,如果每一条的数据太多了,把数据绘制到表格里面会巨慢。
    bzj
        30
    bzj  
       2019-09-27 14:00:22 +08:00
    楼上说不要用*的基本都是半吊子水平,实际上在没有索引的情况下,select * 和 select `field` 效率差不多
    zhuzhibin
        31
    zhuzhibin  
       2019-09-27 14:00:25 +08:00 via iPhone
    没有命中索引哦
    571726193
        32
    571726193  
    OP
       2019-09-27 14:28:32 +08:00
    @javen73 不到 3000 条数据 和 * 不* 的没关系 我始终这么觉得
    571726193
        33
    571726193  
    OP
       2019-09-27 14:29:13 +08:00
    @awanabe select * 走 什么索引
    571726193
        34
    571726193  
    OP
       2019-09-27 14:29:37 +08:00
    @Aresxue 谢谢 老哥 确实 存在这么个情况
    571726193
        35
    571726193  
    OP
       2019-09-27 14:31:35 +08:00
    @golden0125 谢谢 老哥
    571726193
        36
    571726193  
    OP
       2019-09-27 14:32:31 +08:00
    @bzj 是的 实现过 况且 不到 3000 条数据 * 不* 的确实没关系
    haishiwuyuehao
        37
    haishiwuyuehao  
       2019-09-27 14:53:33 +08:00
    那两个查询参数的索引加上了吗。
    照理说不应该啊,才 3000 条数据
    kobayashiro
        38
    kobayashiro  
       2019-09-27 15:54:17 +08:00
    和 * 没关系。。 * 在运行之前会自动解析成字段的。
    你这个首先 索引没上。其次返回了 2000 多条数据 这个数据传输上应该不小
    Egfly
        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%
    awanabe
        40
    awanabe  
       2019-09-27 17:44:02 +08:00
    @571726193 #33 你是执行了你选择的 sql 么..后面没有 where 么

    如果是这样...当我没说哈哈
    519718366
        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,因为他用起来稳定...不会莫名奇妙逆天慢
    panlatent
        42
    panlatent  
       2019-09-27 18:27:40 +08:00
    @519718366 我从 Sequel Pro 换到了 TablePlus
    Macolor21
        43
    Macolor21  
       2019-09-27 21:36:05 +08:00
    @HowardTang
    对接过 2 分钟的接口,用的是 Chunked transfer encoding。每一个 chunk 的速度都是秒级=.=
    cz5424
        44
    cz5424  
       2019-09-27 21:50:49 +08:00 via iPhone
    *不*影响网络传输时间....取一列数据量少....
    zrc
        45
    zrc  
       2019-09-27 22:01:49 +08:00   ❤️ 1
    查询条件是 varchar ?还是 int,遇到过 varchar 然后没加引号很慢的情况
    feiffy
        46
    feiffy  
       2019-09-27 22:12:05 +08:00
    ( 1 )只查询需要的字段
    ( 2 )对查询字段建立索引
    iluckypig
        47
    iluckypig  
       2019-09-27 22:12:44 +08:00
    每行数据是不是很大啊? 3000 条就算没索引没不至于这么慢
    skyqqcc
        48
    skyqqcc  
       2019-09-28 02:21:11 +08:00 via Android
    2H4G 机房 1000M 宽带内网(可能更高),一直都没怎么在乎过性能问题.....😂
    xiaodim
        49
    xiaodim  
       2019-09-28 09:28:28 +08:00
    大家没注意到他的图下方的滑动条吗 看似每行的列字段好多
    tailf
        50
    tailf  
       2019-09-28 09:47:22 +08:00
    肯定是字段很大,下载时间很长
    LuckCode
        51
    LuckCode  
       2019-09-28 11:27:33 +08:00
    1. explain 说的是 all,扫全表。
    2. 你查的结果是 3k 条,但是得到这 3k 条的过程是扫描了全表的,即使前 3k 条就是你要的数据了,sql 还是会扫描完,因为 sql 不知道。
    3. 联合索引有没有用上。
    4. 可能有大量的随机 IO。
    519718366
        52
    519718366  
       2019-10-11 10:04:12 +08:00
    @panlatent 我去体验一波,没准会被你这个 tableplus 给大一统了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3940 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 10:24 · PVG 18:24 · LAX 03:24 · JFK 06:24
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.