这是一个创建于 2066 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚在看高性能 Mysql 的时候突然看到的一个例子，正好又联想起几年前被面试到的一个问题：
Mysql 在查询的时候虽然命中了索引，但是因为该索引对应的记录非常多，达到几百上千万，该如何处理?
书中的解决方法是修改应用代码，区分该类特殊数据，禁止针对这部分条件的查询。 不知道各位有没有更好的解决方案呢
 |
1
veike 2019-03-21 07:24:30 +08:00
处理过 260 万的数据，加了索引查询毫秒级的。只要不 count，只 limit 的速度非常快，count 的话在 0.8s 的花费时间，放服务器上应该更快。
不知道你说的几百万是几。查询到这么多的数据要如何处理，是处理什么呢。 |
 |
2
Varobjs 2019-03-21 07:37:07 +08:00 via Android
使用自增主键当模拟游标，每次 limit
例如 where id > n ＊ 10w and id < n+1 * 10w limit 100 |
 |
3
yidinghe 2019-03-21 07:43:35 +08:00 via Android  4
如果某个索引命中后仍然要在几十万条记录里面挑一两条，那么说明这个索引不适合这个查询，需要另选其他索引。
|
 |
7
agostop 2019-03-21 08:24:29 +08:00
一个索引对应几百万条数据，那么总的数据量是多大？
如果总数据量也就 1 千万，那证明这个索引建的不合适，或者需要配合其他字段来建立索引； 如果索引确实没问题，表的确非常大，那么我想应该先考虑分区比较合适 |
 |
8
Joyboo 2019-03-21 11:04:02 +08:00
同意楼上的，索引命中后还这么大数量级，只能说明这个索引不适合这个场景，数据量大分区是必须的
|
 |
9
reus 2019-03-21 11:19:20 +08:00
那就处理啊
|
 |
10
daviswei 2019-03-21 11:23:00 +08:00
优先考虑从业务逻辑上进行优化，这个是收益最大的。
次选进行分表。 |
 |
11
yangg 2019-03-21 15:14:14 +08:00
@daviswei 和 lz 有同样的问题，业务并不好分表
是一个记录表有 company_id, user_id, price ...其它字段 1, 222, +30 1, 333, -30 1, 444, +30 1, 333, -30 因为公司里所有人的操作的消费都会从 管理员身上扣所以，管理员的数据特别多 这样感觉没法分表，用 company_id 来分表的话，分太多了，也不太好管理。 |
 |
12
snappyone OP @yangg 对的，你这个例子就是书里头写的，因为把很大一部分数据都划归给了 admin，所以导致查询一下命中大量数据，我想了下你是否可以用管理员+其他字段多存一个 hash 到原始表中，下次查询的时候条件就写 where hash=？ and user_id=?
|
 |
15
dengtongcai 2019-03-21 21:11:15 +08:00
换字段建立索引
|
 |
16
qsbaq 2019-03-22 08:59:01 +08:00
就是索引不合适了，需要重新建立。
|
Select Language