③、打铁也要自身硬！因此不断学习提高自己的技术能力，不断总结沟通，才能更好和同事交流，从解决问题的角度出发，去解决问题，创造价值！
五、回归问题本身
上面说的有点跑题了，回到问题本身，说说我对这个性能需求的一些优化建议吧，仅供参考：
1、数据库优化
问题点：从上面描述的情况来看，每天产生的数据大概有10W+条，且只有一张表存储；
解决方案：分库分表，表可以拆分为问卷主表、问卷对应的问题表、问题对应的答案明细表等，长期来说数据量不小，可以考虑分库，主从分离等，查询添加索引等方法。
2、处理逻辑优化
问题点：一次性查询的数据过多，导致前端展示较慢；
解决方案：查询结果分批次展示（比如有100W条数据，分为100个批次，每个批次10000条数据）。
3、存储优化
问题点：没有缓存，直接从DB单表读取，容易造成超时和表锁；
解决方案：将数据放入缓存服务器（比如Redis），设定查询次数或者有效时间，多级缓存，提高缓存命中，防止缓存穿透和同时失效带来的瞬间DB压力。
4、业务优化
问题点：多人短时间内查询大量数据，对服务造成巨大压力；
解决方案：和产品业务沟通，让查询操作时间在业务平缓期，拉长查询操作的时间线等。
5、服务优化
问题点：单台服务器；
解决方案：做服务集群和负载均衡，增加监控，设定阈值，超过阈值则临时增加新的服务器，分流。
本来问题本身只是想说需求分析的，不知不觉扯了很多相关的内容，当然其中有些内容也值得拆开详细讨论，性能测试，水太深啊。。。