V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
ReinerShir
V2EX  ›  MySQL

mysql 的 limit 为什么这么快啊? 1000 多万的表只需要 0.0 几秒

  •  
  •   ReinerShir · 2020-10-29 16:46:41 +08:00 · 5248 次点击
    这是一个创建于 1464 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我使用 explain 看了下,type 是 ALL 走的全表扫描,explain 信息如下:
    rows:10213156 filtered:100.00 select_type:SIMPLE extra:Using where; Using join buffer (hash join)
    mysql 5.8 版本
    有大佬解释下吗?
    21 条回复    2020-11-02 19:36:54 +08:00
    wysnylc
        1
    wysnylc  
       2020-10-29 16:49:22 +08:00   ❤️ 3
    你查第 500 万条试试
    ReinerShir
        2
    ReinerShir  
    OP
       2020-10-29 17:13:03 +08:00
    @wysnylc 哦哦,明白了,btree 的存储是按顺序来的,所以行数小的时候查的很快

    另外还想问下,1000 多万数据的表只要加上索引的话查询时间基本在 0.0 几秒内,似乎并没有分表的必要,能说下数据量要多大,或者说什么业务场景才需要分表吗?
    liuzhaowei55
        3
    liuzhaowei55  
       2020-10-29 17:16:14 +08:00 via Android
    可以对比下不同数据量下 update 语句的时间消耗
    hahasong
        4
    hahasong  
       2020-10-29 17:22:33 +08:00
    表大就别 limit 了,按 id 范围查
    itsql
        5
    itsql  
       2020-10-29 17:27:50 +08:00
    怎么查的,1000 多万的表只需要 0.0 几秒?
    cat
        6
    cat  
       2020-10-29 17:34:58 +08:00 via iPhone
    @itsql 查前几条就可以
    PonysDad
        7
    PonysDad  
       2020-10-29 17:37:15 +08:00
    如果翻到后面的也是,1000w 数量就算 using index 也不可能 0.0 几秒的吧.
    Xusually
        8
    Xusually  
       2020-10-29 17:39:00 +08:00
    分页到后面再试试
    qwerthhusn
        9
    qwerthhusn  
       2020-10-29 17:48:00 +08:00   ❤️ 1
    MySQL 有 5.8 ??
    itsql
        10
    itsql  
       2020-10-29 18:28:27 +08:00
    @cat 哦,这样的,我以为直接查 limit 1000 多万条出来,这么神。
    geekzhu
        11
    geekzhu  
       2020-10-29 18:29:44 +08:00
    @qwerthhusn #9 不就是 MySQL 8 == MySQL 5.8 么?
    dorothyREN
        12
    dorothyREN  
       2020-10-29 19:22:44 +08:00
    limit 快不稀奇,还得看 offset 吧
    qwerthhusn
        13
    qwerthhusn  
       2020-10-29 19:56:18 +08:00
    @geekzhu MySQL8 !== MySQL5_8
    ReinerShir
        14
    ReinerShir  
    OP
       2020-10-30 09:15:11 +08:00
    @liuzhaowei55 是的,如果不使用 ID 或索引做为更新条件,时间会很长


    @qwerthhusn MYSQL8 ,5.7 突然改名 8 没转过来

    @hahasong 如果 ID 不是连续的就不行吧? 那样会少条数,比如 1-10 的 ID 中间少了 8,那么根据>=1 and <=10 就会只查出 9 条,不知道我理解的对不对。
    ReinerShir
        15
    ReinerShir  
    OP
       2020-10-30 10:17:52 +08:00
    @hahasong 查了一下,你说的是这种吗:select * from TEST_SUB_ORDER A join (
    select id from TEST_SUB_ORDER S ORDER BY ID limit 10000000,20) AS B ON A.ID=B.ID

    即使用这种方式查询时间还是长达 4 秒,请问有办法控制在 1 秒内吗?
    aragakiyuii
        16
    aragakiyuii  
       2020-10-30 10:43:53 +08:00
    '如果 ID 不是连续的就不行吧? 那样会少条数,比如 1-10 的 ID 中间少了 8,那么根据>=1 and <=10 就会只查出 9 条,不知道我理解的对不对。'

    用这种 'where id > xx limit 10'
    hahasong
        17
    hahasong  
       2020-10-30 10:59:11 +08:00
    @ReinerShir #15 楼上正解
    ReinerShir
        18
    ReinerShir  
    OP
       2020-10-30 16:18:34 +08:00
    @aragakiyuii
    @hahasong 是的,我试了下用 ID 分页中间少了条数据就会不对,没有其它好的办法了吗?
    aragakiyuii
        19
    aragakiyuii  
       2020-10-30 17:13:19 +08:00 via iPhone
    @ReinerShir #18 别把 id 的值当成 offset 算
    分页的时候前台把显示的最后一条记录的 id 传过来,每页记录条数传过来。查询的时候用 where id > #{previousId} limit #{pageSize}
    ReinerShir
        20
    ReinerShir  
    OP
       2020-11-02 09:58:36 +08:00
    @aragakiyuii 这种做法有致命缺点,如果我跳页,比如一开始是第一页,我直接点第 8 页,那么就没有 previousId,你说的这种只能一页一页的点
    aragakiyuii
        21
    aragakiyuii  
       2020-11-02 19:36:54 +08:00
    @ReinerShir #20 确实是,不过这些感觉都是“假需求”。。。1000w+的数据谁会一页一页或者跳页看。。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   977 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 21:37 · PVG 05:37 · LAX 14:37 · JFK 17:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.