本文复盘一次标准差判读功能的性能优化合并查询、建立内存索引、减少重复遍历并修复历史实现中的结果覆盖等问题。文中结论以源码和业务观察为依据新旧结果是否一致尚未经过同批数据验证。1. 背景与问题现象这是实验室质控平台的能力验证判读功能。组织方把同一批质控样本分发给各实验室各实验室上报检测值平台按样本类别汇总所有机构的值计算均值M和样本标准差S再用|x − M|与1S / 1.5S / 2S / 3S比较给出单样本评价最后合成机构综合评价。判读有三条入口详情页、成绩计算和 Excel 导出三条路径使用同一套判读逻辑。数据来自filling_sample、qa_task_details、qa_task_sample三张表qa_filling_tasks.status用于过滤有效填报。优化前详情页业务侧需要等待10 秒以上改造后降到约 1 秒。这个数字来自实际使用中的观察并非正式压测没有记录并发量、机器环境和 P95因此不能把它表述为所有场景下都稳定提升十倍。2. 性能瓶颈定位旧实现先查任务明细再查检测值。两条查询都在循环外所以问题不是 N1真正的浪费发生在 Java 端的数据处理。// detailsBySample、valuesBySample 是两条查询结果按样本类别分组后的 MapfillingTaskMap.forEach((labId,lab)-{// F 家机构qaTaskSampleMap.forEach((sampleId,sample)-{// S 类样本detailsBySample.get(sampleId).forEach(detail-{// 约 F 条明细// 旧代码此处用明细 ID 查按样本类别 ID 建的索引valuesBySample.get(detail.getId()).stream().collect(Collectors.groupingBy(CodeValueBySample::getId));});});});问题集中在三处外层已经在遍历机构内层却再次取出“该类样本下所有机构的明细”在索引能命中的前提下同一批记录会被重复处理约F次最内层对已经查到的记录重新groupingBy、toMap属于重复分组和重复查找结果集合也在明细循环内创建和添加带来了结果覆盖、重复添加等问题见第 5 节。旧实现已经在循环外计算均值和标准差这部分不是本次优化新增的收益。3. SQL 查询优化旧实现先查任务明细select *带det.del_flag 0没有状态过滤再查检测值关联qa_task_details按status in (2,4,5)过滤。两条 SQL 在qa_task_details上重复取数。合并后的查询只取必要字段并保留状态过滤selectdet.filling_task_id,det.qa_task_sample_id,sample.valuefromfilling_sample samplejoinqa_task_details detondet.idsample.qa_task_details_idwheresample.template_instance_item_info_id#{dataSourceId}anddet.task_id#{taskId}andexists(select1fromqa_filling_tasks fwheref.iddet.filling_task_idandf.statusin(2,4,5))这组判读数据查询中减少了一次数据库访问也少传输了一份任务明细结果集行数取决于实际明细数量记为D少做了一次 Java 侧分组。示例省略了实际 SQL 中的det.id、qs.name、det.sample_code等字段数据库端收益仍取决于执行计划本文未做 SQL 日志对比。有两点结果范围差异必须保留不能宣称新旧 SQL 完全等价旧明细查询带det.del_flag 0新查询没有如果存在逻辑删除的任务明细结果集范围会不同。旧明细查询没有状态过滤新查询只保留status in (2,4,5)。其中2、4在实体注释中分别对应“已填报”“已评分”5没有注释说明本文不推断其业务含义。4. 内存索引与循环优化拿到N条检测记录后先按两个访问路径建立索引。这里的all是批量查询返回的记录sampleIndex是“样本类别 id - 样本对象”的有序 Map。下面的代码为突出索引与循环结构做了简化省略了结果组装、异常处理和业务分支不是可直接替换生产实现的完整代码。// 样本类别 - 该类样本下所有机构的检测值用于统计MapLong,ListCodeValueBySamplebySampleall.stream().collect(Collectors.groupingBy(CodeValueBySample::getQaTaskSampleId));// 机构 - 该机构的检测值用于逐家判读// key 是 qa_filling_tasks.id与 fillingTaskMap 的 key 同维度MapLong,ListCodeValueBySamplebyFillingTaskall.stream().collect(Collectors.groupingBy(CodeValueBySample::getFillingTaskId));均值和标准差是样本级不变量在机构循环外只算一次MapLong,BigDecimalmeanMapnewHashMap();MapLong,BigDecimalsdMapnewHashMap();sampleIndex.forEach((sampleId,sample)-{ListCodeValueBySamplesampleValuesbySample.get(sampleId);if(sampleValuesnull||sampleValues.isEmpty()){thrownewIllegalStateException(缺少检测记录需按业务规则处理);}ListBigDecimalvaluessampleValues.stream().map(CodeValueBySample::getValue).collect(Collectors.toList());meanMap.put(sampleId,EquipStdDevUtils.mean(values,10));sdMap.put(sampleId,EquipStdDevUtils.sampleStandardDeviation(values,10));});判读时按机构循环在机构级建立一次“样本类别 - 记录”的索引再按样本直接查找ListSampleStdDevQaFillingTaskresultsnewArrayList();// fillingTaskMap: qa_filling_tasks.id - SampleStdDevQaFillingTaskbyFillingTask.forEach((labId,labValues)-{// labId 是 getFillingTaskId() 返回的 qa_filling_tasks.idSampleStdDevQaFillingTasklabfillingTaskMap.get(labId);if(labnull){thrownewIllegalStateException(缺少机构任务记录需按业务规则处理);}MapString,ObjectsampleMapnewLinkedHashMap();MapLong,CodeValueBySamplevalueIndexlabValues.stream().collect(Collectors.toMap(CodeValueBySample::getQaTaskSampleId,e-e,(oldValue,newValue)-oldValue));sampleIndex.forEach((sampleId,sample)-{CodeValueBySamplerecordvalueIndex.get(sampleId);BigDecimalmeanmeanMap.get(sampleId);BigDecimalsdsdMap.get(sampleId);// record、value、mean、sd 都可能缺失处理规则待业务确认if(recordnull||record.getValue()null||meannull||sdnull){thrownewIllegalStateException(缺少样本记录或统计量需按业务规则处理);}BigDecimalsampleValuerecord.getValue();BigDecimalabsValuesampleValue.subtract(mean.setScale(1,RoundingMode.HALF_UP)).abs();// 用 absValue 与 1S / 1.5S / 2S / 3S 比较 ...sampleMap.put(sample.getName(),sampleValue);// 组装展示字段简化});lab.setSample(sampleMap);// 每家机构只组装一次// 计算综合评价并回填 lab.setResult(...)此处省略results.add(lab);});说明本节示例中的IllegalStateException只是为避免空指针而写的示意占位不代表生产实现缺失数据是报错、跳过还是按其他规则处理仍需业务确认。核心变化只有两点内层只处理当前机构自己的V条记录重复的stream groupingBy变成一次索引构建 O(1)查找。当前仓库仍把valueIndex建在样本循环内上面是整理后的前置写法属于等价小改动每机构少建S - 1次索引V很小时收益有限不计入已上线的优化。toMap的合并函数保留第一条前提是同一机构同一类别至多一条有效记录若有复测或多指标共用字段后续记录会被静默丢弃需先明确聚合规则。5. 优化效果与正确性检查结果是业务侧观察到的 10 秒以上降到约 1 秒查询合并、索引与循环调整、缺陷修复这三类改动对耗时的贡献无法拆分不能把收益全部归因于某一种优化。复杂度变化设F为机构数S为样本类别数V为每机构每类样本的检测记录数N为批量查询返回的记录总数。数据均衡时N ≈ F × S × V。版本记录处理量说明旧实现约F × N每家机构都把全量数据再走一遍新实现约N查询、分组、统计、索引和查找各一遍旧实现F × N的前提是每机构每类一条明细、索引能命中、每条明细V条记录。旧代码索引键不一致可能提前失败所以这是结构量级不是实测。新实现为O(N)的前提是N ≈ F × S × VV ≥ 1、每家机构都要遍历S个样本类别这样F × S的查找项会被N吸收若V 0或数据严重不平衡应按实际记录数和实际遍历次数分别估算。索引与记录同阶空间复杂度O(N)。正确性检查与本次重构直接相关的源码问题有三类样本结果 Map 在明细循环内创建同一机构的结果会被后续明细覆盖results.add(...)位于明细循环内同一机构对象可能被重复添加旧代码用明细 ID 查询按样本类别 ID 建立的索引两个 ID 不属于同一维度可能取不到数据。新版按机构循环组装和添加各一次。但这些只是源码确认不是生产故障统计新旧结果尚未同批对比仓库也没有自动化测试。待确认风险缺失记录含状态3机构、重复记录以及单样本判定用 1 位小数均值、综合评价用 1 位小数差值带来的阈值边界差异。需业务确认本文不设默认行为。6. 总结与实践经验这次优化没有复杂技巧主要是三件事合并查询先确认查询是否真的在循环里。旧实现的两条查询都在循环外问题不是 N1而是查询结果存在重叠、后续又重复处理。按访问路径建索引按样本统计就建“样本 - 记录”按机构判读就建“机构 - 记录”把重复遍历换成一次分组和直接查找。不变量前置均值、标准差和阈值倍数与机构无关放在循环外只算一次。
本文复盘一次标准差判读功能的性能优化合并查询、建立内存索引、减少重复遍历并修复历史实现中的结果覆盖等问题。文中结论以源码和业务观察为依据新旧结果是否一致尚未经过同批数据验证。1. 背景与问题现象这是实验室质控平台的能力验证判读功能。组织方把同一批质控样本分发给各实验室各实验室上报检测值平台按样本类别汇总所有机构的值计算均值M和样本标准差S再用|x − M|与1S / 1.5S / 2S / 3S比较给出单样本评价最后合成机构综合评价。判读有三条入口详情页、成绩计算和 Excel 导出三条路径使用同一套判读逻辑。数据来自filling_sample、qa_task_details、qa_task_sample三张表qa_filling_tasks.status用于过滤有效填报。优化前详情页业务侧需要等待10 秒以上改造后降到约 1 秒。这个数字来自实际使用中的观察并非正式压测没有记录并发量、机器环境和 P95因此不能把它表述为所有场景下都稳定提升十倍。2. 性能瓶颈定位旧实现先查任务明细再查检测值。两条查询都在循环外所以问题不是 N1真正的浪费发生在 Java 端的数据处理。// detailsBySample、valuesBySample 是两条查询结果按样本类别分组后的 MapfillingTaskMap.forEach((labId,lab)-{// F 家机构qaTaskSampleMap.forEach((sampleId,sample)-{// S 类样本detailsBySample.get(sampleId).forEach(detail-{// 约 F 条明细// 旧代码此处用明细 ID 查按样本类别 ID 建的索引valuesBySample.get(detail.getId()).stream().collect(Collectors.groupingBy(CodeValueBySample::getId));});});});问题集中在三处外层已经在遍历机构内层却再次取出“该类样本下所有机构的明细”在索引能命中的前提下同一批记录会被重复处理约F次最内层对已经查到的记录重新groupingBy、toMap属于重复分组和重复查找结果集合也在明细循环内创建和添加带来了结果覆盖、重复添加等问题见第 5 节。旧实现已经在循环外计算均值和标准差这部分不是本次优化新增的收益。3. SQL 查询优化旧实现先查任务明细select *带det.del_flag 0没有状态过滤再查检测值关联qa_task_details按status in (2,4,5)过滤。两条 SQL 在qa_task_details上重复取数。合并后的查询只取必要字段并保留状态过滤selectdet.filling_task_id,det.qa_task_sample_id,sample.valuefromfilling_sample samplejoinqa_task_details detondet.idsample.qa_task_details_idwheresample.template_instance_item_info_id#{dataSourceId}anddet.task_id#{taskId}andexists(select1fromqa_filling_tasks fwheref.iddet.filling_task_idandf.statusin(2,4,5))这组判读数据查询中减少了一次数据库访问也少传输了一份任务明细结果集行数取决于实际明细数量记为D少做了一次 Java 侧分组。示例省略了实际 SQL 中的det.id、qs.name、det.sample_code等字段数据库端收益仍取决于执行计划本文未做 SQL 日志对比。有两点结果范围差异必须保留不能宣称新旧 SQL 完全等价旧明细查询带det.del_flag 0新查询没有如果存在逻辑删除的任务明细结果集范围会不同。旧明细查询没有状态过滤新查询只保留status in (2,4,5)。其中2、4在实体注释中分别对应“已填报”“已评分”5没有注释说明本文不推断其业务含义。4. 内存索引与循环优化拿到N条检测记录后先按两个访问路径建立索引。这里的all是批量查询返回的记录sampleIndex是“样本类别 id - 样本对象”的有序 Map。下面的代码为突出索引与循环结构做了简化省略了结果组装、异常处理和业务分支不是可直接替换生产实现的完整代码。// 样本类别 - 该类样本下所有机构的检测值用于统计MapLong,ListCodeValueBySamplebySampleall.stream().collect(Collectors.groupingBy(CodeValueBySample::getQaTaskSampleId));// 机构 - 该机构的检测值用于逐家判读// key 是 qa_filling_tasks.id与 fillingTaskMap 的 key 同维度MapLong,ListCodeValueBySamplebyFillingTaskall.stream().collect(Collectors.groupingBy(CodeValueBySample::getFillingTaskId));均值和标准差是样本级不变量在机构循环外只算一次MapLong,BigDecimalmeanMapnewHashMap();MapLong,BigDecimalsdMapnewHashMap();sampleIndex.forEach((sampleId,sample)-{ListCodeValueBySamplesampleValuesbySample.get(sampleId);if(sampleValuesnull||sampleValues.isEmpty()){thrownewIllegalStateException(缺少检测记录需按业务规则处理);}ListBigDecimalvaluessampleValues.stream().map(CodeValueBySample::getValue).collect(Collectors.toList());meanMap.put(sampleId,EquipStdDevUtils.mean(values,10));sdMap.put(sampleId,EquipStdDevUtils.sampleStandardDeviation(values,10));});判读时按机构循环在机构级建立一次“样本类别 - 记录”的索引再按样本直接查找ListSampleStdDevQaFillingTaskresultsnewArrayList();// fillingTaskMap: qa_filling_tasks.id - SampleStdDevQaFillingTaskbyFillingTask.forEach((labId,labValues)-{// labId 是 getFillingTaskId() 返回的 qa_filling_tasks.idSampleStdDevQaFillingTasklabfillingTaskMap.get(labId);if(labnull){thrownewIllegalStateException(缺少机构任务记录需按业务规则处理);}MapString,ObjectsampleMapnewLinkedHashMap();MapLong,CodeValueBySamplevalueIndexlabValues.stream().collect(Collectors.toMap(CodeValueBySample::getQaTaskSampleId,e-e,(oldValue,newValue)-oldValue));sampleIndex.forEach((sampleId,sample)-{CodeValueBySamplerecordvalueIndex.get(sampleId);BigDecimalmeanmeanMap.get(sampleId);BigDecimalsdsdMap.get(sampleId);// record、value、mean、sd 都可能缺失处理规则待业务确认if(recordnull||record.getValue()null||meannull||sdnull){thrownewIllegalStateException(缺少样本记录或统计量需按业务规则处理);}BigDecimalsampleValuerecord.getValue();BigDecimalabsValuesampleValue.subtract(mean.setScale(1,RoundingMode.HALF_UP)).abs();// 用 absValue 与 1S / 1.5S / 2S / 3S 比较 ...sampleMap.put(sample.getName(),sampleValue);// 组装展示字段简化});lab.setSample(sampleMap);// 每家机构只组装一次// 计算综合评价并回填 lab.setResult(...)此处省略results.add(lab);});说明本节示例中的IllegalStateException只是为避免空指针而写的示意占位不代表生产实现缺失数据是报错、跳过还是按其他规则处理仍需业务确认。核心变化只有两点内层只处理当前机构自己的V条记录重复的stream groupingBy变成一次索引构建 O(1)查找。当前仓库仍把valueIndex建在样本循环内上面是整理后的前置写法属于等价小改动每机构少建S - 1次索引V很小时收益有限不计入已上线的优化。toMap的合并函数保留第一条前提是同一机构同一类别至多一条有效记录若有复测或多指标共用字段后续记录会被静默丢弃需先明确聚合规则。5. 优化效果与正确性检查结果是业务侧观察到的 10 秒以上降到约 1 秒查询合并、索引与循环调整、缺陷修复这三类改动对耗时的贡献无法拆分不能把收益全部归因于某一种优化。复杂度变化设F为机构数S为样本类别数V为每机构每类样本的检测记录数N为批量查询返回的记录总数。数据均衡时N ≈ F × S × V。版本记录处理量说明旧实现约F × N每家机构都把全量数据再走一遍新实现约N查询、分组、统计、索引和查找各一遍旧实现F × N的前提是每机构每类一条明细、索引能命中、每条明细V条记录。旧代码索引键不一致可能提前失败所以这是结构量级不是实测。新实现为O(N)的前提是N ≈ F × S × VV ≥ 1、每家机构都要遍历S个样本类别这样F × S的查找项会被N吸收若V 0或数据严重不平衡应按实际记录数和实际遍历次数分别估算。索引与记录同阶空间复杂度O(N)。正确性检查与本次重构直接相关的源码问题有三类样本结果 Map 在明细循环内创建同一机构的结果会被后续明细覆盖results.add(...)位于明细循环内同一机构对象可能被重复添加旧代码用明细 ID 查询按样本类别 ID 建立的索引两个 ID 不属于同一维度可能取不到数据。新版按机构循环组装和添加各一次。但这些只是源码确认不是生产故障统计新旧结果尚未同批对比仓库也没有自动化测试。待确认风险缺失记录含状态3机构、重复记录以及单样本判定用 1 位小数均值、综合评价用 1 位小数差值带来的阈值边界差异。需业务确认本文不设默认行为。6. 总结与实践经验这次优化没有复杂技巧主要是三件事合并查询先确认查询是否真的在循环里。旧实现的两条查询都在循环外问题不是 N1而是查询结果存在重叠、后续又重复处理。按访问路径建索引按样本统计就建“样本 - 记录”按机构判读就建“机构 - 记录”把重复遍历换成一次分组和直接查找。不变量前置均值、标准差和阈值倍数与机构无关放在循环外只算一次。
