比如 where id in (...),如果里面几条或者十几条还是很快的,但是我们需要一次查出上万条不同 id 的数据,该怎办,这时候 explain 显示的全表扫了
比如 where id in (...),如果里面几条或者十几条还是很快的,但是我们需要一次查出上万条不同 id 的数据,该怎办,这时候 explain 显示的全表扫了
|
mayday526Nov 20, 2018
1
用 in 查询的那个字段加上索引试试
|
|
utf16Nov 20, 2018
2
exists 了解一下
|
|
lucnNov 20, 2018
3
拆分成多个查询呗,每次少查点,id 是主键的话,上万个主键查找,查询引擎优化成表扫描不是很正常么
|
|
sfqtshNov 20, 2018 via Android
4
in 几万几十万 走索引也不是很快了,,pg
|
|
limuyan44Nov 20, 2018 via Android
5
优化完就直接扫表了,能同时查肯定有业务特征的啊,加个字段吧。
|
|
dezhou9Nov 20, 2018 via Android
6
字典树匹配
|
|
mmdsunNov 20, 2018 via Android
7
in MySQL 默认有一定的优化。我看是 in 太多了 MySQL 判断不走索引了。可以强制索引:select * from table force index(索引)
|
|
Raymon111111Nov 20, 2018
8
for 循环分批
|
|
U7Q5tLAex2FI0o0gNov 20, 2018
9
分页?
|
|
ImmortalNov 20, 2018
10
2l 给思路了 有个 in 和 exists 转化的 具体 google 下
|
|
zhangZMZNov 20, 2018
13
force index
|
|
zhangZMZNov 20, 2018
14
mysql 在 10W 以内是没问题的
|
|
akagishigeruNov 20, 2018 via iPhone
15
分批次走索引吧
|
|
HuHuiNov 20, 2018 via Android
16
先从业务入手吧
|
|
jimrokNov 20, 2018
17
用 nosql,memcached 和 redis 都有类似的方法,可以一次返回多个 key 的数据。上万个,你这个业务也有点问题吧?难道每次不做分页?
|
|
18
因为要扫描的记录数量确实有这么多,这时候索引已经没有办法继续帮助优化扫描过程了。那么一种策略就是尽快返回。查询 id 的语句执行完后,一边从 cursor 取 id,一边分批次对这些 id 做后面的操作。
|
|
lxerxaNov 20, 2018 via iPhone
19
考虑用 exists
|
|
zhangZMZNov 21, 2018
25
目前看来这个问题的解决需要依赖于楼主是否是妹子,而且是否漂亮、有没有男朋友了。
|