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

[ReinerShir]

我使用 explain 看了下，type 是 ALL 走的全表扫描，explain 信息如下：
rows:10213156 filtered:100.00 select_type:SIMPLE extra:Using where; Using join buffer (hash join)
mysql 5.8 版本
有大佬解释下吗？

[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}

[ReinerShir]

@aragakiyuii 这种做法有致命缺点，如果我跳页，比如一开始是第一页，我直接点第 8 页，那么就没有 previousId，你说的这种只能一页一页的点

[aragakiyuii]

@ReinerShir #20 确实是，不过这些感觉都是“假需求”。。。1000w+的数据谁会一页一页或者跳页看。。