Mysql 命中索引后仍然有大量数据该如何处理

[snappyone]

刚在看高性能 Mysql 的时候突然看到的一个例子，正好又联想起几年前被面试到的一个问题：

Mysql 在查询的时候虽然命中了索引，但是因为该索引对应的记录非常多，达到几百上千万，该如何处理?

书中的解决方法是修改应用代码，区分该类特殊数据，禁止针对这部分条件的查询。 不知道各位有没有更好的解决方案呢

[veike]

处理过 260 万的数据，加了索引查询毫秒级的。只要不 count，只 limit 的速度非常快，count 的话在 0.8s 的花费时间，放服务器上应该更快。
不知道你说的几百万是几。查询到这么多的数据要如何处理，是处理什么呢。

[Varobjs]

使用自增主键当模拟游标，每次 limit
例如 where id > n ＊ 10w and id < n+1 * 10w limit 100

[yidinghe]

如果某个索引命中后仍然要在几十万条记录里面挑一两条，那么说明这个索引不适合这个查询，需要另选其他索引。

[des]

@veike
如果是要 group by 然后 order，再 limit 呢？

[anyele]

@des 那就很慢

[veike]

@des 来个具体的 group by order limit

[agostop]

一个索引对应几百万条数据，那么总的数据量是多大？
如果总数据量也就 1 千万，那证明这个索引建的不合适，或者需要配合其他字段来建立索引；
如果索引确实没问题，表的确非常大，那么我想应该先考虑分区比较合适

[Joyboo]

同意楼上的，索引命中后还这么大数量级，只能说明这个索引不适合这个场景，数据量大分区是必须的

[reus]

那就处理啊

[daviswei]

优先考虑从业务逻辑上进行优化，这个是收益最大的。
次选进行分表。

[yangg]

@daviswei 和 lz 有同样的问题，业务并不好分表
是一个记录表有
company_id, user_id, price ...其它字段
1, 222, +30
1, 333, -30
1, 444, +30
1, 333, -30
因为公司里所有人的操作的消费都会从 管理员身上扣所以，管理员的数据特别多
这样感觉没法分表，用 company_id 来分表的话，分太多了，也不太好管理。

[snappyone]

@yangg 对的，你这个例子就是书里头写的，因为把很大一部分数据都划归给了 admin，所以导致查询一下命中大量数据，我想了下你是否可以用管理员+其他字段多存一个 hash 到原始表中，下次查询的时候条件就写 where hash=？ and user_id=?

[snappyone]

@veike 应不一样，不是总表百万，是单纯一条查询命中索引后依然还有百万级数据

[snappyone]

@daviswei 我犹记得我当初面试也是这么说的，但是人家说不考虑业务，就只能技术解决

[dengtongcai]

换字段建立索引

[qsbaq]

就是索引不合适了，需要重新建立。