新入职一家公司后，前三天一直在学习公司内部各种制度文化以及考试。
一直到第三天组长突然叫我过去，给了一个需求的思维导图，按照这个需求写这样一个接口，
其实还不错，不用自己去分析需求，按照这上面直接开写。还有基本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
SELECT
id, SUM( price* call_count) / 6 AS averageAmount
FROM
table_name
WHERE
id > (
SELECT
MIN( id)
FROM
table_name
WHERE
statistics_date = DATE_FORMAT( DATE_SUB( NOW(
),
INTERVAL 180 DAY),
'%Y-%m-%d'
)
)
AND id in( 156)
GROUP BY
id
这段sql一开始确实不理解什么意思，因为是组长优化后直接发给我的，先叫我看看为什么这么做。仔细一看我以为组长写错啦。因为我们要计算的是6个月的平均值 你们statistics_date 后应该是大于等于，不应该是等于。
于是怕到时候数据出错我又去问了问组长，终于明白
SELECT
MIN( id)
FROM
table_name
WHERE
statistics_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先执行外层的sql，in是先执行内层的子查询。
- exists与in的区别二：exists使用的是内层的索引，in使用的是外层的索引。
所以当in里面的数据量不大时，使用in效率大于exists。当子查询数据量大于外层查询时，使用exists效率大于in
第三次提交
性能测试通过，但是数据对不上
原因
通过接口查询出来的数据和给测试的sql查出来数据不一致。
解决
这种问题有些棘手。为什么呢？因为计算数据走缓存，猜想：可能是缓存里面数据不一致问题。
当然前提是保证所有代码计算逻辑没问题。
查缓存，将缓存里面的数据和数据库里面查出来数据做对比。经过一番对比排查。
果然是数据不一致问题。
虽然数据不一致问题在缓存架构里面是比较常见的问题。但是公司那么久的项目肯定不会出现这么低级的错误。
请教了组长，果然揪出端倪。
原来是sql语句里面少啦一些状态为不可用的条件。
最后做数据对比完全一致。
关于组长给我代码做的一些优化
我的思路
在此之前因为保证数据准确性还要先遍历一次参数ids，然后取出参数id对应的值
这样减少两次循环，在代码层面也做了一些优化。
