
比如 where id in (...),如果里面几条或者十几条还是很快的,但是我们需要一次查出上万条不同 id 的数据,该怎办,这时候 explain 显示的全表扫了
1 mayday526 2018-11-20 17:55:00 +08:00 用 in 查询的那个字段加上索引试试 |
2 utf16 2018-11-20 17:57:31 +08:00 exists 了解一下 |
3 lucn 2018-11-20 17:59:23 +08:00 拆分成多个查询呗,每次少查点,id 是主键的话,上万个主键查找,查询引擎优化成表扫描不是很正常么 |
4 sfqtsh 2018-11-20 18:00:05 +08:00 via Android in 几万几十万 走索引也不是很快了,,pg |
5 limuyan44 2018-11-20 18:12:44 +08:00 via Android 优化完就直接扫表了,能同时查肯定有业务特征的啊,加个字段吧。 |
6 dezhou9 2018-11-20 18:22:49 +08:00 via Android 字典树匹配 |
7 mmdsun 2018-11-20 18:52:52 +08:00 via Android in MySQL 默认有一定的优化。我看是 in 太多了 MySQL 判断不走索引了。可以强制索引:select * from table force index(索引) |
8 Raymon111111 2018-11-20 19:48:27 +08:00 for 循环分批 |
9 U7Q5tLAex2FI0o0g 2018-11-20 20:05:26 +08:00 分页? |
10 Immortal 2018-11-20 20:08:20 +08:00 2l 给思路了 有个 in 和 exists 转化的 具体 google 下 |
13 zhangZMZ 2018-11-20 20:24:32 +08:00 force index |
14 zhangZMZ 2018-11-20 20:24:49 +08:00 mysql 在 10W 以内是没问题的 |
15 akagishigeru 2018-11-20 21:07:36 +08:00 via iPhone 分批次走索引吧 |
16 HuHui 2018-11-20 21:10:33 +08:00 via Android 先从业务入手吧 |
17 jimrok 2018-11-20 21:14:02 +08:00 用 nosql,memcached 和 redis 都有类似的方法,可以一次返回多个 key 的数据。上万个,你这个业务也有点问题吧?难道每次不做分页? |
18 yidinghe 2018-11-20 21:15:41 +08:00 via Android 因为要扫描的记录数量确实有这么多,这时候索引已经没有办法继续帮助优化扫描过程了。那么一种策略就是尽快返回。查询 id 的语句执行完后,一边从 cursor 取 id,一边分批次对这些 id 做后面的操作。 |
19 lxerxa 2018-11-20 21:36:45 +08:00 via iPhone 考虑用 exists |
22 cc959798 OP @lxerxa 大佬,这种怎么改 select * from tb_name where id in (123,321,231) 就一张表 |
25 zhangZMZ 2018-11-21 18:35:15 +08:00 目前看来这个问题的解决需要依赖于楼主是否是妹子,而且是否漂亮、有没有男朋友了。 |