标签：sql 方案 客户 结合 一致性 移动 计数 改变 生产
前两天把阶段性的成果部署到了客户的生产环境，期间遇到了很多问题，也学习到了很多以前不知道的知识，这里记录一下。
1.之前一篇随笔，说了统计数据使用了两种确定表头的方式的结合，一是根据统计维度的全集字典值来确定，二是如果统计维度的值过多（上百个），那么这类统计维度则根据统计结果来确定表头。但是，两者结合的方式在前端分行查询的展示下十分不友好，因为是分页统计数据，若使用两种方式结合来确定表头，则每一页的表头都是不确定的，是变化的，这样用户肯定会感到十分费解。所以最终还是把表头确定的方式改为了统一用从字典中获取。如果出现很长的统计维度，那么考虑在前端使用一些折叠的特效来提升用户体验。
2.SpringBoot项目打包步骤：1).先将application.yml的配置设置为prod 2). clean -> rebuild -> package 3).将打包好的jar包， application-prod.yml文件以及conf配置文件放到服务器即可。这里不得不说springboot的打包还是很方便的，而且配置文件的分离使得更改配置也非常方便。
3.在服务器启动sb项目的命令： nohup java -jar yourapp.jar --spring.config.location=application-pord.yml
4.关于数据采集的顺序问题，之前说过做统计之前是需要先把数据采集回本地的（全量采集），而且因为有来自不同数据源的数据，我们希望能将不同数据的采集相互间的影响降到最低，所以实现了统一接口的不同的服务类被设计出来并发的采集不同的数据源。另外，对于单个数据源来说，采集过程中如果出现问题，也是需要进行处理的。这里最终的采集设计是：
1）若临时表中有数据，先把临时表数据清空
2）将数据采集到临时表中
2.1）然后如果本次采集到临时表顺利完成，则再将临时表的数据全部移动到正式表（insert into table_name_new select * from table_bak)；
2.2）如果采集中因为问题而中断，则清空临时表再重新采集或者进行其它处理（问题排查）。
这种备份方式，相比较于插入主表后在移动到备份表上有一个更好的地方，那就是能够保证主表中的数据总归能被用作统计，因为是全量采集，需要先清空表再操作，如果先清空主表再采集，如果中途出错则可能导致统计无法进行。而先采集到临时表的方案则不存在这个问题。
**这里在具体实现的时候还踩了两个坑：
1）insert into table_name_new select * from table_bak这个sql语句在执行的时候要求两张表的字段创建顺序是一致的，orcal不会自动根据列名去匹配，而是根据列的顺序，只要数据类型能够匹配就会将table_bak中对应的字段复制到table_name_new表中去。所以这种复制操作一定要保证两个建表sql中字段的一致性。当时因为bak表中多一个字段，我用可视化工具删除后，顺序改变，导致采集的数据和数据源数据不匹配，这种问题不好排查，所以一定要防微杜渐。
2）第二个情况是，因为数据是分页采集到bak表中的，而oracle中的分页需要用到rownum这个关键字。有趣的是，在采集的过程中，如果被采集的源表中数据发生变化，那么rownum也就会相应的发生变化，比如源表中增加了新的数据记录，那么此时会导致分页获取的数据有重复的现象，当时就踩了这个坑。因为正式统计的数据表是有主键约束的，而bak临时表没有主键约束，所以在复制数据（步骤2.1）时，会触发唯一约束。这里解决方法也很简单，只需要加上distinct关键字就行了: insert into table_name_new select distinct * from table_bak （这里没考虑数据删除的情况，因为需要统计的数据一般都是重要数据，很少会出现删除的情况，另外，讲道理如果是删除导致rownum变化的话，那么可以考虑在采集前先count总数，然后采集完再核对，如果count数量少了，那么从新采集）。
暂时的整理就这么多，项目在现场遇到的问题远不止这些，还有很多要学，加油。
标签：sql 方案 客户 结合 一致性 移动 计数 改变 生产
原文地址：https://www.cnblogs.com/singular/p/11920498.html
