彩妆网站建设报告,互联网创始人,网站建设 微信公众号运营,丹阳建站新入职一家公司后#xff0c;前三天一直在学习公司内部各种制度文化以及考试。
一直到第三天组长突然叫我过去#xff0c;给了一个需求的思维导图#xff0c;按照这个需求写这样一个接口#xff0c; 其实还不错#xff0c;不用自己去分析需求#xff0c;按照这上面直接开…新入职一家公司后前三天一直在学习公司内部各种制度文化以及考试。
一直到第三天组长突然叫我过去给了一个需求的思维导图按照这个需求写这样一个接口 其实还不错不用自己去分析需求按照这上面直接开写。还有基本sql语句也给我了存粹是让我练手的。 接下来就是各种环境配置账号申请。 版本控制工具使用的是Gitlab
第一次代码提交 毫无悬念被打回来啦 原因 没有使用缓存公司项目还是一个多年的大项目有着自己的缓存技术和体系所有查询一般都是先走缓存因为我的那个入参ids是多个客户id按逗号拼接而来的。所以可能在全量测试的时候根本扛不住。
解决 请教同事和组长公司项目的缓存规范以及如何使用。
接下来就是查找自己所有需要的API接口啦结合同事的使用方法自己去调用实现自己业务。
第二次代码提交
代码提交通过但是测试不通过 原因 全量测试时无反应部分ID报空指针异常。 解决 对所有的可能出现的空指针对象进行校验 针对无反应现象做了如下优化
原来的sql SELECT id, SUM( price* call_count) / 6
FROM table_name
WHERE statistics_date DATE_FORMAT( DATE_SUB( NOW(
),
INTERVAL 180 DAY),
%Y-%m-%d %H:%i:%s
)
AND id in( 156)
GROUP BY id原来的sql 优化后的sql
SELECTid, SUM( price* call_count) / 6 AS averageAmountFROMtable_nameWHEREid (SELECTMIN( id)FROMtable_nameWHEREstatistics_date DATE_FORMAT( DATE_SUB( NOW(),INTERVAL 180 DAY),%Y-%m-%d))AND id in( 156) GROUP BY id这段sql一开始确实不理解什么意思因为是组长优化后直接发给我的先叫我看看为什么这么做。仔细一看我以为组长写错啦。因为我们要计算的是6个月的平均值 你们statistics_date 后应该是大于等于不应该是等于。 于是怕到时候数据出错我又去问了问组长终于明白
SELECTMIN( id)FROMtable_nameWHEREstatistics_date DATE_FORMAT( DATE_SUB( NOW(),INTERVAL 180 DAY),%Y-%m-%d)这段sql是查询6个月前的那一天数据找到这天当中id最小的然后在外面的查询中查询id大于这个最小id的就是近6个月的数据因为ID是只增的且id作为主键索引查询效率肯定大于我之前写的sql。 继续优化sql in函数的性能问题 当传递过来的参数长度较小时使用in语句查询效率还是比较高的当测试做全量测试时参数长度在1000-2000之间 那么就要考虑使用exists 为什么
exists与in的区别一exists先执行外层的sqlin是先执行内层的子查询。exists与in的区别二exists使用的是内层的索引in使用的是外层的索引。
所以当in里面的数据量不大时使用in效率大于exists。当子查询数据量大于外层查询时使用exists效率大于in
第三次提交
性能测试通过但是数据对不上 原因 通过接口查询出来的数据和给测试的sql查出来数据不一致。 解决 这种问题有些棘手。为什么呢因为计算数据走缓存猜想可能是缓存里面数据不一致问题。 当然前提是保证所有代码计算逻辑没问题。 查缓存将缓存里面的数据和数据库里面查出来数据做对比。经过一番对比排查。 果然是数据不一致问题。 虽然数据不一致问题在缓存架构里面是比较常见的问题。但是公司那么久的项目肯定不会出现这么低级的错误。 请教了组长果然揪出端倪。 原来是sql语句里面少啦一些状态为不可用的条件。 最后做数据对比完全一致。
关于组长给我代码做的一些优化
我的思路 在此之前因为保证数据准确性还要先遍历一次参数ids然后取出参数id对应的值 这样减少两次循环在代码层面也做了一些优化。
