刚在看高性能 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
就是索引不合适了,需要重新建立。
|