优化 OR 条件过多导致的查询超时
文章目录
背景
在生成年度累积报表时，需要根据排产订单中的【工厂、物料、BOM版本】进行分组查询。尤其是在数据量较大的情况下（例如 2024 年 1-7 月的排产数据），生成报表时遇到了查询超时问题。这主要是由于分组查询后的数据量较大，且查询中使用了大量的 OR 条件。
本文将探讨针对这种场景的优化策略，并提供不同的解决方案以供参考。具体使用哪种方案，应根据实际业务需求及数据量大小来选择。
问题分析
以下代码片段展示了问题的根源。在处理过程中，代码基于输入参数列表循环拼接 OR 条件。由于输入的列表包含了数千条记录，这种大量的 OR 条件在数据库中执行时导致了性能问题，最终导致查询超时。
// 自制UPH单价
List<PriceBillZzUphInfo> priceBillZzUphInfoParamList = orwAnnualProductionOrderList.stream()
.map(item -> new PriceBillZzUphInfo()
.setFactoryCode(item.getProductFactoryCode())
.setMaterialParentCode(item.getProductMaterialCode())
.setBomVersion(item.getBomVersion())
)
.collect(Collectors.toList());
List<PriceBillZzUphInfo> priceBillZzUphInfoResultList = this.priceBillZzUphInfoProviderService.getByMatAndFacAndBom(priceBillZzUphInfoParamList);
// getByMatAndFacAndBom
public List<PriceBillZzUphInfo> getByMatAndFacAndBom(List<PriceBillZzUphInfo> list) {
if (CollUtil.isEmpty(list)) {
return Collections.emptyList();
}
LambdaQueryWrapper<PriceBillZzUphInfo> lambdaQueryWrapper = Wrappers.lambdaQuery();
lambdaQueryWrapper
.and(queryWrapper -> {
queryWrapper.eq(PriceBillZzUphInfo::getStatus, 1);
})
.and(queryWrapper -> {
list.forEach(item -> {
queryWrapper.or(query -> {
query.eq(PriceBillZzUphInfo::getMaterialParentCode, item.getMaterialParentCode());
query.eq(PriceBillZzUphInfo::getFactoryCode, item.getFactoryCode());
query.eq(PriceBillZzUphInfo::getBomVersion, item.getBomVersion());
});
});
});
return list(lambdaQueryWrapper);
}
在该场景中，orwAnnualProductionOrderList 涉及的数据时间范围是[上个月所在年的第一天, 上个月的最后一天]，该时间范围内的数据需要根据【工厂代码】、【物料代码】和【BOM版本】进行多条件查询。
生成的 SQL 如下：
SELECT *
FROM price_bill_zz_uph_info
WHERE deleted = 1
AND ((status = 1) AND ((material_parent_code = '0031800390C' AND factory_code = '80G0' AND bom_version = '02') OR
(material_parent_code = '0021800126A' AND factory_code = '80K0' AND bom_version = '10') OR
.........;
方案分析
该问题的最终定位便是 SQL 的查询超时，所以解决方案也是围绕解决该 SQL 的查询效率问题，可以从 SQL 和业务等方面进行优化。
方案一：入参去重
直接原因是入参过多，导致了 SQL 拼接条件过多。所以先对入参进行去重，但是去重后的入参仍然有七千多条，仍旧超时。所以该方案不可行。
方案二：分页或者分批查询
使用分页查询，因为不确定具体的符合条件的数据量，所以无法简便且准确的进行分页查询。
分批查询，将入参进行分批，比如每一千条或一百条查询一次，该方案可以控制在有效时间内返回数据并进行处理。但是该方案会造成多次查询数据库，且 OR 条件过多会导致索引失效，在数据量较大时，查询效率仍旧会低。
所以，分页或者分批查询在本次业务场景下可行性低。
方案三：UNION 代替 OR
使用 UNION 来代替 OR 条件查询，这是在进行 SQL 优化时的一种方案。但是在本次业务背景下，OR 条件查询参数过多，会造成很多 union 拼接，并不合理。
方案四：IN 代替 OR
使用 IN 条件语句代替 OR 条件查询有两种形式：
1. 分别对列进行 IN 查询，在代码中进行数据筛选。
queryWrapper.in(PriceBillZzUphInfo::getMaterialParentCode, materialCodeList)
.in(PriceBillZzUphInfo::getFactoryCode, factoryCodeList)
.in(PriceBillZzUphInfo::getBomVersion, bomVersionList);
在 mybatis-plus 中使用如上的 Wrapper 条件，查询出所有数据后，再根据入参进行有效数据的获取。该方案可以正常获取数据并进行处理，但是 IN 条件查询参数过多时会造成索引失效，导致效率较慢。
2. 对多列进行 IN 查询。
在 SQL 层面使用多条件 IN 查询。XML 文件内容如下：
SELECT material_parent_code, factory_code, bom_version, qt_attr2_price
FROM price_bill_zz_uph_info
WHERE status = 1 AND deleted = 1 AND (material_parent_code, factory_code, bom_version) IN
<foreach collection="list" item="item" open="(" separator="," close=")">
(#{item.materialParentCode},#{item.factoryCode},#{item.bomVersion})
</foreach>
对应的 SQL语句如下：
SELECT material_parent_code, factory_code, bom_version, qt_attr2_price
FROM price_bill_zz_uph_info
WHERE status = 1 AND deleted = 1 AND (material_parent_code, factory_code, bom_version) IN
(('0041800262KA', '8783', '03'), ('0041800808', '8710', '03'), ('0041800808', '8710', '03')......);
查看执行计划：
查看执行计划发现可以使用索引，而且执行时间要比原 SQL 短，但是依旧要几秒甚至十几秒。
小结
使用 IN 条件查询来代替 OR 可以在一定程度上缓解查询慢的问题，但是在该业务场景下，更多的原因是因为入参的数据量比较大，所以 I/O 耗时严重，而且 MySQL 的服务器层在解析优化该 SQL 时耗时也会多一些，各方面原因导致了整体耗时仍旧较高。
方案五：JOIN 查询（采用）
使用 JOIN 查询，直接在 SQL 中进行时间范围的控制，在 ON 条件中进行参数控制，并添加如下索引：
CREATE INDEX index_mat_factory_bom_attr2
ON price_bill_zz_uph_info (material_parent_code, factory_code, bom_version, qt_attr2_price);
CREATE INDEX idx_mat_factory_bom
ON inf_orw_annual_production_order (product_material_code, product_factory_code, bom_version);
SQL 语句：
SELECT t.material_parent_code, t.factory_code, t.bom_version, t.qt_attr2_price
FROM price_bill_zz_uph_info t
LEFT JOIN (SELECT product_factory_code, product_material_code, bom_version
FROM inf_orw_annual_production_order
WHERE orw_actual_end_time BETWEEN #{beginTime} AND #{endTime}) o
ON t.material_parent_code = o.product_material_code AND
t.factory_code = o.product_factory_code AND t.bom_version = o.bom_version
GROUP BY t.material_parent_code, t.factory_code, t.bom_version;
查看执行计划，发现均可以使用索引：
)
采用方案要点分析
上述方案五中，要注意以下几点：
联合索引的顺序
联合索引的列顺序是物料、工厂、BOM 版本，因为数据的区分度是物料>工厂>BOM 版本，以该方式建立索引，可以提高索引的有效利用率。
条件查询的顺序
条件查询列的顺序要跟联合索引的列顺序对应，防止索引失效，要遵循最左匹配原则。
精简查询字段
在该需求中，因为只需要 t.material_parent_code, t.factory_code, t.bom_version, t.qt_attr2_price 这四列的值即可，所以对于 price_bill_zz_uph_info 表建立的联合索引也多加了一列 qt_attr2_price，这样做的目的是为了减少 MySQL 的回表。
要根据具体的需求来确定索引，如果查询条件列过多，并不适合将所有的列全部放到索引中，因为维护索引也有资源和性能的损耗。
LEFT JOIN 使用中间表
不是直接 JOIN inf_orw_annual_production_order 表，像如下 SQL 会造成索引失效。
SELECT t.*
FROM price_bill_zz_uph_info t
LEFT JOIN inf_orw_annual_production_order o
ON t.material_parent_code = o.product_material_code AND
t.factory_code = o.product_factory_code AND t.bom_version = o.bom_version
WHERE o.orw_actual_end_time BETWEEN '2024-01-01 00:00:00' AND '2024-07-31 23:59:59'
GROUP BY t.material_parent_code, t.factory_code, t.bom_version;
查看执行计划：
总结
在大数据量、高复杂度的查询场景下，简单的 OR 条件可能导致严重的性能问题。通过合理的查询优化策略，如批量处理、索引优化、使用临时表、以及查询重构，可以显著改善查询性能，避免超时问题。
这些优化方法应结合业务需求和实际数据量灵活应用，以确保在维持系统性能的同时满足业务需求。
标签：code,查询,material,factory,过多,version,bom,超时 From： https://blog.csdn.net/Youth_Mr6/article/details/142318232