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

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

  •  
  •   571726193 · 117 天前 · 5910 次点击
    这是一个创建于 117 天前的主题,其中的信息可能已经有所发展或是发生改变。

    在这里插入图片描述

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

    可以满足?
    5200
        29
    5200   117 天前
    直接 mysql 命令模式连接 127.0.0.1 试试,然后不要用*。
    用一些可视化工具,如果每一条的数据太多了,把数据绘制到表格里面会巨慢。
    bzj
        30
    bzj   117 天前
    楼上说不要用*的基本都是半吊子水平,实际上在没有索引的情况下,select * 和 select `field` 效率差不多
    zhuzhibin
        31
    zhuzhibin   117 天前 via iPhone
    没有命中索引哦
    571726193
        32
    571726193   117 天前
    @javen73 不到 3000 条数据 和 * 不* 的没关系 我始终这么觉得
    571726193
        33
    571726193   117 天前
    @awanabe select * 走 什么索引
    571726193
        34
    571726193   117 天前
    @Aresxue 谢谢 老哥 确实 存在这么个情况
    571726193
        35
    571726193   117 天前
    @golden0125 谢谢 老哥
    571726193
        36
    571726193   117 天前
    @bzj 是的 实现过 况且 不到 3000 条数据 * 不* 的确实没关系
    haishiwuyuehao
        37
    haishiwuyuehao   117 天前
    那两个查询参数的索引加上了吗。
    照理说不应该啊,才 3000 条数据
    kobayashiro
        38
    kobayashiro   117 天前
    和 * 没关系。。 * 在运行之前会自动解析成字段的。
    你这个首先 索引没上。其次返回了 2000 多条数据 这个数据传输上应该不小
    Egfly
        39
    Egfly   117 天前
    ![navicat 剖析]( https://cdn.learnku.com/uploads/images/201909/27/33663/cwUC7cv2O7.png!/fw/1240)
    查询之后可以先看看剖析,看一下是那个步骤耗时最多。我截图中就是 sending data 的动作耗时最多,占了 65%
    awanabe
        40
    awanabe   117 天前
    @571726193 #33 你是执行了你选择的 sql 么..后面没有 where 么

    如果是这样...当我没说哈哈
    519718366
        41
    519718366   117 天前
    这是 mysql workbench 辣鸡而已,莫慌....我也遇到过你这个情况
    workbench 逆天用时,然后用 sequel 执行了下很正常。

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

    现在基本在用 sequel,因为他用起来稳定...不会莫名奇妙逆天慢
    panlatent
        42
    panlatent   117 天前
    @519718366 我从 Sequel Pro 换到了 TablePlus
    Macolor21
        43
    Macolor21   116 天前
    @HowardTang
    对接过 2 分钟的接口,用的是 Chunked transfer encoding。每一个 chunk 的速度都是秒级=.=
    cz5424
        44
    cz5424   116 天前 via iPhone
    *不*影响网络传输时间....取一列数据量少....
    zrc
        45
    zrc   116 天前
    查询条件是 varchar ?还是 int,遇到过 varchar 然后没加引号很慢的情况
    feiffy
        46
    feiffy   116 天前
    ( 1 )只查询需要的字段
    ( 2 )对查询字段建立索引
    iluckypig
        47
    iluckypig   116 天前
    每行数据是不是很大啊? 3000 条就算没索引没不至于这么慢
    skyqqcc
        48
    skyqqcc   116 天前 via Android
    2H4G 机房 1000M 宽带内网(可能更高),一直都没怎么在乎过性能问题.....😂
    xiaodim
        49
    xiaodim   116 天前
    大家没注意到他的图下方的滑动条吗 看似每行的列字段好多
    tailf
        50
    tailf   116 天前
    肯定是字段很大,下载时间很长
    LuckCode
        51
    LuckCode   116 天前
    1. explain 说的是 all,扫全表。
    2. 你查的结果是 3k 条,但是得到这 3k 条的过程是扫描了全表的,即使前 3k 条就是你要的数据了,sql 还是会扫描完,因为 sql 不知道。
    3. 联合索引有没有用上。
    4. 可能有大量的随机 IO。
    519718366
        52
    519718366   103 天前
    @panlatent 我去体验一波,没准会被你这个 tableplus 给大一统了
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2156 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 24ms · UTC 12:55 · PVG 20:55 · LAX 04:55 · JFK 07:55
    ♥ Do have faith in what you're doing.