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

• 資深大佬 : wysnylc

  你查第 500 万条试试

• 主 資深大佬 : ReinerShir

  @wysnylc 哦哦，明白了，btree 的存储是按顺序来的，所以行数小的时候查的很快

  另外还想问下，1000 多万数据的表只要加上索引的话查询时间基本在 0.0 几秒内，似乎并没有分表的必要，能说下数据量要多大，或者说什么业务场景才需要分表吗？

• 資深大佬 : liuzhaowei55

  可以对比下不同数据量下 update 语句的时间消耗

• 資深大佬 : hahasong

  表大就别 limit 了，按 id 范围查

• 資深大佬 : itsql

  怎么查的，1000 多万的表只需要 0.0 几秒？

• 資深大佬 : cat

  @itsql 查前几条就可以

• 資深大佬 : PonysDad

  如果翻到后面的也是,1000w 数量就算 using index 也不可能 0.0 几秒的吧.

• 資深大佬 : Xusually

  分页到后面再试试

• 資深大佬 : qwerthhusn

  MySQL 有 5.8 ？？

• 資深大佬 : itsql

  @cat 哦，这样的，我以为直接查 limit 1000 多万条出来，这么神。

• 資深大佬 : geekzhu

  @qwerthhusn #9 不就是 MySQL 8 == MySQL 5.8 么？

• 資深大佬 : dorothyREN

  limit 快不稀奇，还得看 offset 吧

• 資深大佬 : qwerthhusn

  @geekzhu MySQL8 !== MySQL5_8

• 主 資深大佬 : ReinerShir

  @liuzhaowei55 是的，如果不使用 ID 或索引做为更新条件，时间会很长

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

  @hahasong 如果 ID 不是连续的就不行吧？ 那样会少条数，比如 1-10 的 ID 中间少了 8，那么根据>=1 and <=10 就会只查出 9 条，不知道我理解的对不对。

• 主 資深大佬 : ReinerShir

  @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

  ‘如果 ID 不是连续的就不行吧？ 那样会少条数，比如 1-10 的 ID 中间少了 8，那么根据>=1 and <=10 就会只查出 9 条，不知道我理解的对不对。’

  用这种 ‘where id > xx limit 10’

• 資深大佬 : hahasong

  @ReinerShir #15 上正解

• 主 資深大佬 : ReinerShir

  @aragakiyuii
  @hahasong 是的，我试了下用 ID 分页中间少了条数据就会不对，没有其它好的办法了吗？

• 資深大佬 : aragakiyuii

  @ReinerShir #18 别把 id 的值当成 offset 算
  分页的时候前台把显示的最后一条记录的 id 传过来，每页记录条数传过来。查询的时候用 where id > #{previousId} limit #{pageSize}