事情是这样的，测试提了个bug，说我一个报表页面总合计算错了，作为一个每天bug沾身的小小弟，早已经习惯了，估计就是合计的sql少了哪个条件导致的，然后拿参数跑了一下，确定眼没花，sql是对的。
这下我就怀疑测试测错了吧，但是人家录了个视屏，视屏里放着计算器一页一页的加的。
我自己加一遍吧，然后我加了5，6，7，8遍，人家是对的，我当时就懵了。
更神奇的是，我把分页换到最大，包含了所有页，然后，然后，神奇的事发生了，总合计没变，单页合计变得和总合计一样了，这就意味着如果是单页的时候，数据是对的，分页了数据就错了。
怀疑一下mysql分页？不至于吧，做了这么多年的分页都是这样写的啊。
于是我把分页调到每页40条，计算了一下单页汇总金额和总合计金额对比，仍然是对的。我再把分页调到20，问题出现了，单页汇总金额加起来和总合计金额查了300块，人都麻了。
我把sql执行，把每页20条数据全部一页页拿出来拼起来，然后不分页的数据一下拿出来，做了一个文件对比，发现还真不一样，第二页的数据排序是不一致的，而且好像数据也一样。
最后真的找到了按20条分页的数据里有两条和不分页的数据是不一样的。按20条分页的数据里有一天完全和第一页某一条数据重了，就意味着数据混乱了，重复了。
这下是真的麻了，就是分页的问题。
折腾了大半天，就是mysql的问题，后来去找到了，是limit + order by 被sql优化了，order by 一个字段有多个重复值的时候可能会出现这种情况，并不是先排序完了再分页。
解决办法，就是order by字段最后面再加一个唯一的id啥的，这样估计就导致没被sql优化了吧。
这下我就开始怀疑自己了，以前做了一麻堆项目，写了那么分页，前端传递的orderBy参数，或者后端orderBy自己写死的分页参数,搞不好数据就是有问题的，虽然这个出现应该是多字段排序。
抱着忐忑的心，扒了当前整个项目的分页，发现一个很有趣的事，好多分页排序要么都是单字段排序，要么就是带了editTime了，只有这个报表那么奇葩。
其实，如果页面上分页数据不会存在这种单页汇总，单页导出，你完全不用在意，在页面上操作，数据重复的基本不会出现在同一页，数据条数也不会错。你觉得可能漏掉数据对吧，按条件搜索这条丢失的数据，你也会看到。反正嘛，就是糊糊涂涂的过，阴差阳错的对。
这确实是一个自己知识区域很大的一个盲区，这里可能是优化sql速度的问题，其实我想了想，如果没有这种报表单页需求，还要单页导出的，就不必要加id了，如果需要一点问题没有，那就加个id吧，估计就排序没得优化了。 想想以前写的，也算不得bug嘛
