面试最后一问把我整懵了

一般报表涉及都是运算统计排序为主，
这种数据量大的，
统计结果时效性是保证不了的，都是离线统计导出的
因为他提到了了分页慢，就知道用了大量的 order by 和分页，命中索引只能优化前面的几十万的数据，当分页去到第 200 万行，后面性能就很低了，
简单合理便宜处理办法就是根据需要计算的字段，自定义计算，丢内存运算，然后导出来，不够再加磁盘，所以数据结构就很重要了

年度的一年才做一次吧，没有 dwh 之类的吗

@huntcool001 对，这也是我想说的。

我做过 20 亿条单个表的数据库。其实以主键排序 20 亿并不会慢。而索引的问题在于，如果加索引的列有大量重复的值的时候，索引是无效的。所以一般索引只对主键，或者时间戳比较有效。这个时候要么分表，要么上 elasticsearch 。都是挺好的解决办法。

@laminux29 这个问题的本质难道不是考察你问诊的能力？
面试官问了一个模糊场景的问题，作为程序员难道不是去尝试缩小问题点，找到具体问题在哪，然后再针对优化？
让你猜场景和算法？难道不是让你问他场景和算法然后去缩小问题？

就说经典的面试问题，如果用户输入了你的网站地址，按下回车，但是网站迟迟不加载，问题在哪。你不去一步一步分析场景缩小范围找到问题点，坐在那里傻瞪着面试官，那人家不拒你留着过年么。

年度数据报表？我觉得可以问一下是不是实时更新的，不是的话可以考虑预渲染？

@veike 不连续不影响，只要递增就行

clickhouse 列存数据库了解一下

select 字段 from 表 where id in （ select id from 表 limit x x ）网上好像搜到过这种答案……

多数人都回答错了。。。
面试官想要你说的是“使用 nosql 分组缓存统计”

B 神的问题哈哈哈哈！

索引、缓存、分表。

根据 id：select * from (select id from 表 limit xx,xx) a left join 表 b on a.id = b.id

@msg7086 [考察] 二字已经意味着不平等的关系。在这种关系下，你再牛逼，对方也能保留解释权地筛掉你。

数据量大分页不要用 limit offset，用 keyset 分页。

@laminux29 我并没有否认不平等关系。但是不平等关系和羞辱和否决和否定都没有决定性的联系。
考察的目的是找出那些人符合面试官认为的适合公司的候选人，筛掉你当然是因为你不符合面试官心目中的候选人形象。

年度数据报表肯定是要缓存的，一年就出一次的东西，实时计算何必呢，设定个计划任务，一月的某一个半夜算他几个小时，整个一年都有的看

这种具体的项目问题，并不是封闭式问题，没有什么标准答案。一般来说，你能给出越多的可行性提升性能方法，表现越好。当然，也可以从整个业务流的优化说起，也就是从浏览器到 web server，再到缓存，业务模块，数据库这些环节，每一个地方都有可优化的方法。最后，如果是优化 SQL，可以使用执行计划考察一下 SQL 慢在哪里。

emmm 。。。。楼上有些说千万级数据没有浏览需求的，我只能说我之前做过的一个系统还真有。。。
流水报表，一张表上亿都有，当然不可能是一页展示完，支持各种条件分页查询。

加索引这种回答不应该是无工作经验的面试回答吗？工作经验大于一年敢回答这么简单果断是不能要的

’加索引’这个回答太初级啦。如果自己真的经验很丰富，可以说出很多来。
比如用 limit o, n 分页， 随着分页越来越大，速度会越来越慢，怎么优化呢？
根据查询条件，如何做索引优化呢 ？
千万级数据量可以分库分表；
数据库选型用 mysql, pg，mongo, greenplum.. .. . . .
随便 bala 可以说半个小时了

@nortonlai
@zhuifeng1017

可能确实是我表达不当，“加索引”不是我回答的全部。我想表达的意思是，我提出的“加索引”、“分库分表”这些解决方向没有像预期的那样得到正向反馈。

确实也是经验不够导致的吧。当时的状态过于被动，说完自己想法之后就在等面试官能给点提示。如果能沉住气去追问然后再给出别的解决方案应该会得到更好的结果。

@zhouyou457
这就是日志型数据库的事情了。