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

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

MySQL

explain

using

join

21 条回复 • 2020-11-02 19:36:54 +08:00

wysnylc

2020-10-29 16:49:22 +08:00

你查第 500 万条试试

ReinerShir

2020-10-29 17:13:03 +08:00

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

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

liuzhaowei55

2020-10-29 17:16:14 +08:00 via Android

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

hahasong

2020-10-29 17:22:33 +08:00

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

itsql

2020-10-29 17:27:50 +08:00

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

cat

2020-10-29 17:34:58 +08:00 via iPhone

@itsql 查前几条就可以

PonysDad

2020-10-29 17:37:15 +08:00

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

Xusually

2020-10-29 17:39:00 +08:00

分页到后面再试试

qwerthhusn

2020-10-29 17:48:00 +08:00

MySQL 有 5.8 ？？

itsql

2020-10-29 18:28:27 +08:00

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

geekzhu

2020-10-29 18:29:44 +08:00

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

dorothyREN

2020-10-29 19:22:44 +08:00

limit 快不稀奇，还得看 offset 吧

qwerthhusn

2020-10-29 19:56:18 +08:00

@geekzhu MySQL8 !== MySQL5_8

ReinerShir

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

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

2020-10-30 10:43:53 +08:00

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

用这种 'where id > xx limit 10'

hahasong

2020-10-30 10:59:11 +08:00

@ReinerShir #15 楼上正解

ReinerShir

2020-10-30 16:18:34 +08:00

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

aragakiyuii

2020-10-30 17:13:19 +08:00 via iPhone

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

ReinerShir

2020-11-02 09:58:36 +08:00

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

aragakiyuii

2020-11-02 19:36:54 +08:00

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