今天做的事：

和曾添讨论了一番，发现自己实在是太low了，菜的被狗日，要学的东西太多了；不过也有很多启发，尤其对于微信开发这块有了新的头绪。

或许这就是大佬把，仅仅是一个多小时的谈话，给我带来了很多信息，并且很多启发。

晚上和另一位大佬，茹程远合作做一个由张帆大佬安排的任务，总结一些修真院的java相关内容。

再晚点，和阿飞把sql语句写一下。

今天和阿飞把Excel表格做了一些，还差最后一块，出现了一个问题：

就是关系表出现了问题。

我大概描述一下问题吧：

首先存在用户和文章两个表，然后用户和文章是多对多关系；这时候会出现一个关系表；这些其实没什么，问题的关键是：

当我们看文章列表页的时候，当前用户收藏过的文章就会需要渲染；这个时候问题就出现了：

首先我通过用户id在关系表中查出一个列表，内容是：用户收藏过的文章id，姑且叫做listC；

接下来，我从文章表中取出listA，这个时候，需要做一个匹配：把listC中的数据匹配到listA中，需要一个双重for循环，上层是循环遍历listC，内层是循环遍历listA，当有id匹配的时候，更改一个状态标识，前端通过这个做相应的渲染。

这时候有个很严重的问题：我们还需要对listA做时间格式转换，所以最后操作的数据量相当于“（n+1）*N”，其中n是listC的大小；N是listA的大小。

这是极其损耗性能的操作！

所以我们想到了分页，这样可以每页只处理10条数据，那么就会大大降低损耗到“（n+1）*10”；但是这个时候问题又出现了，这块才是最关建的问题：

首先，该接口每次只返回10条数据，所以，每次请求的时候就会出现最开始的10条记录不见了；好吧，这块据说前端可把每次返回的list保存，那么就暂时解决这个问题了，但是真正解决了么？

可以看一下，真正的严重问题如下图

这时候，我大概想了这样的解决方案：前端在每次获取list的时候，可不可以和之前保存的那些次请求接口得到的list（10条数据）进行对比，如果之前存在，那么就不渲染出来，所以每次点击“获取”按钮，可能会出现加载并没有10条的情况，不过这块还没有向前端确认，所以暂时在这里记录，并且有哪位大佬看到这个问题的时候，可以不吝赐教，狠狠的教育我一番，跪求！（比如更好的优化方案，或者比较合理的解决方案能够解决性能问题什么的）

明天计划：明天准备做方案评审

问题：上面描述的就是最大的问题，其他小问题都在它面前黯然失色

收获：Excel表格快要完成了