上线小结——坑和教训

上周，公司上线了全新打造的理财师服务平台及飞单平台。

首先纪念下人生加过最长的班。从周五早上9点到公司，到周日早上7点半离开。当中断断续续只趴在桌子上睡了几个小时

预定周五上线。看着缺陷从几百个减少到两个。没想到野火烧不尽，春风吹又生了。再集成、UAT、准生产到生产再一堆问题……

每次上线总会遇到各种坑和前期没注意的点。总结下，有利于将来避免与改进。但是48个小时实在是迷迷糊糊，记得什么写什么吧……

标绿为错误方式

标红为建议方式

 

1.Integer Bigdecimal这种非基本数据类型比较，绝对不能用==，而应该用compareTo   equals等。数字相等，也很可能比较出来是不等的。当然存在有可能能相等，但是是特殊情况下，之后另外撰文详述。这种坑非常隐蔽。如果开发人员本身没有这个概念，更是不会想到是这个问题导致逻辑不对。要定位到具体模块，再单步调试才能找到。找到也想不出为什么。个人观点，对于开发人员来说，语言的基础，常规坑，实现细节比算法本身更重要。

2.mybatis的入参类型如果是BigDecimal   入参数据为0的时候，mybatis会将其转换为null   如果update时进行!=null 的判断的话，可能不会执行对应的set语句。

3.数据库表变更控制。上线过程中，发现根据数据库sql脚本执行后的数据库，与测试库的表结构存在差异。之后只能通过手工修复。这说明数据库表的变更没有完全按照流程走。不能开发和测试随意修改测试库。表变更均应通过某一个或一组人进行。保证脚本与库的一致。将来应更关注流程控制

4.测试环境发生了很奇怪的问题。明明测试人员描述只是为某项目添加了配置并做了一次变更，按理说应该是更新第一次录入的一组数据。却莫名奇妙变成了数据库中出现了两组数据。原来，开发方案为：第一次录入没有id，系统生成id，变更时先查询后变更，如果id字段不为空，则update。为空则insert。这样的判断其实是不够准确的。不考虑真正并发的情况下，这种方式都有可能卡不住。如果录入人员先打开了某项目的配置页面，之后有开一个，分别填写后提交。提交至后台都没有id，都会insert，都会绑定到同一个项目上。互联网与传统软件不同。必须考虑重复操作，重复提交，并发访问，交叉执行等情况。

5.压测中，账户中心页面数据库CPU占用严重。loadrunner设置50并发就到瓶颈了。仔细看了下，发现好几个问题：

　　<1>账户中心页面因为有大量的统计，比如持有中项目数量，申请中项目数量，而这多达10几个的统计，在一个接口，一个事务内完成。可以考虑将其拆分为多个接口。一个大接口很容易发生超时

　　<2>部分是从子查询中统计，建议写成 select count(1) from (select id from ……)，而不是select count(1) from (select * from ……)，因为对于count(1)来说子查询不需要查询出所有列，只需要最简单的非null的一列就够了

　　<3>存在select count(1) from (select count(1) from ……)这种诡异的写法。还没有和开发人员确认过这么写的目的，为了判断是否表中有符合查询条件的数据？但肯定有更合适的写法

　　<4>好几处SQL语句是从上面类似的查询中copy过来的，可是在select中存在很多这次查询不需要的列。建议删除

　　<5>比如某表内存在查询条件完全一致，只是类型不同的数据需要分别统计。不应多次按类型查询。建议一次查询按group by分组统计数量，如果个别类型存在多的查询条件，可以将该列一起返回，由应用程序另做过滤。个人观点，部分操作交给数据库不如交给应用，代码实现也容易，而且理论上应用可以扩展，而数据库永远是热点且扩展不易

 

　　暂时就想到这些。想起什么另作补充。

转载于:https://www.cnblogs.com/keita/p/8716305.html