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

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

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

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

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

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