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

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

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

    在这里插入图片描述

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

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

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

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

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