任何抛开业务谈大数据量的sql优化都是瞎扯

周三去某在线旅游公司面试。被问到了一个关于数据量大的优化问题。问题是:一个主外键关联表,主表有一百万数据,外键关联表有一千万的数据,要求做一个连接。

本人接触过单表数据量最大的就是将近两亿行历史数据(某运营商一业务一年数据)做查询,所有查询相关列必须做索引,而且还要保证不会出现全表扫描情况。也从来没有试过把这么多数据全部拿出来放内存中。只好回答说“再怎么做优化估计都不行,这数据量太大了,性能肯定吃不销。我只能告诉尽可能的添加过滤条件,不要一次用这么多的数据来做连接,能分批做就分批做吧”。

面试人员告诉我,比如说我们的机票业务,我们只把北上广热门城市的放在缓存中,实时刷新即可。其他的每次去查询数据库即可,不必一次把所有的数据全部连接出来放到内存中。

我只能呵呵了,没有业务让我去优化一个sql,这不是扯淡么。

关于这种大数据量优化问题,让我理解最深刻就是分表做法。因为我们公司有个业务需要实时上传数据,每天小百万数据,而且还要做查询。于是分表来做,每天生成一张表,然后把前一天的表添加索引,查询的时候可以根据日期来获取表名。尽量少查询当天数据,因为没有索引比较慢。添加索引的话因为实时插入数据,索引的维护代价比较大,所以选择第二天添加前一天表的索引。

上一篇:mysql大数据量下的分页


下一篇:Python面向对象编程(上)