1
wysnylc 2020-10-29 16:49:22 +08:00 3
你查第 500 万条试试
|
2
ReinerShir OP @wysnylc 哦哦,明白了,btree 的存储是按顺序来的,所以行数小的时候查的很快
另外还想问下,1000 多万数据的表只要加上索引的话查询时间基本在 0.0 几秒内,似乎并没有分表的必要,能说下数据量要多大,或者说什么业务场景才需要分表吗? |
3
liuzhaowei55 2020-10-29 17:16:14 +08:00 via Android
可以对比下不同数据量下 update 语句的时间消耗
|
4
hahasong 2020-10-29 17:22:33 +08:00
表大就别 limit 了,按 id 范围查
|
5
itsql 2020-10-29 17:27:50 +08:00
怎么查的,1000 多万的表只需要 0.0 几秒?
|
7
PonysDad 2020-10-29 17:37:15 +08:00
如果翻到后面的也是,1000w 数量就算 using index 也不可能 0.0 几秒的吧.
|
8
Xusually 2020-10-29 17:39:00 +08:00
分页到后面再试试
|
9
qwerthhusn 2020-10-29 17:48:00 +08:00 1
MySQL 有 5.8 ??
|
11
geekzhu 2020-10-29 18:29:44 +08:00
@qwerthhusn #9 不就是 MySQL 8 == MySQL 5.8 么?
|
12
dorothyREN 2020-10-29 19:22:44 +08:00
limit 快不稀奇,还得看 offset 吧
|
13
qwerthhusn 2020-10-29 19:56:18 +08:00
@geekzhu MySQL8 !== MySQL5_8
|
14
ReinerShir OP @liuzhaowei55 是的,如果不使用 ID 或索引做为更新条件,时间会很长
@qwerthhusn MYSQL8 ,5.7 突然改名 8 没转过来 @hahasong 如果 ID 不是连续的就不行吧? 那样会少条数,比如 1-10 的 ID 中间少了 8,那么根据>=1 and <=10 就会只查出 9 条,不知道我理解的对不对。 |
15
ReinerShir OP |
16
aragakiyuii 2020-10-30 10:43:53 +08:00
'如果 ID 不是连续的就不行吧? 那样会少条数,比如 1-10 的 ID 中间少了 8,那么根据>=1 and <=10 就会只查出 9 条,不知道我理解的对不对。'
用这种 'where id > xx limit 10' |
17
hahasong 2020-10-30 10:59:11 +08:00
@ReinerShir #15 楼上正解
|
18
ReinerShir OP |
19
aragakiyuii 2020-10-30 17:13:19 +08:00 via iPhone
@ReinerShir #18 别把 id 的值当成 offset 算
分页的时候前台把显示的最后一条记录的 id 传过来,每页记录条数传过来。查询的时候用 where id > #{previousId} limit #{pageSize} |
20
ReinerShir OP @aragakiyuii 这种做法有致命缺点,如果我跳页,比如一开始是第一页,我直接点第 8 页,那么就没有 previousId,你说的这种只能一页一页的点
|
21
aragakiyuii 2020-11-02 19:36:54 +08:00
@ReinerShir #20 确实是,不过这些感觉都是“假需求”。。。1000w+的数据谁会一页一页或者跳页看。。
|