遍历全量列表过滤与多次访问数据库查询，哪种实现方案更优？

两种方案优劣对比 #

没有绝对的最优解，需结合业务场景判断，具体分析如下：

• 原方案：实时查询数据库

public List<Element> method(String text) {  
    List<Element> element = select * from element e where e.text like text
    return element
}

优势：

1. 不占用应用服务内存存储全量数据，适合element表数据量较大（万级以上、单条数据体积大）的场景，不会引发应用内存溢出风险
2. 可获取实时最新数据，适配element表数据频繁更新的业务
3. 若text字段已加适配模糊查询的索引（如like语句为前缀匹配text%格式），数据库查询性能远高于应用层遍历
   劣势：
4. 高频调用时会产生大量数据库请求，容易打满数据库连接、拉高数据库负载，导致整体响应变慢
5. 每次请求都存在数据库IO开销，单请求响应延迟高于内存计算

• 改造方案：全量加载内存遍历
  全量预加载代码：

List<Element> allElement = select * from element

业务方法代码：

public List<Element> method(String text) {  
    List<Element> element; 
    for Element e : allElement{
      if e.text.contains(text) element.add(e)
    }
    return element
}

优势：

1. 全量数据仅需加载一次（可搭配定时刷新逻辑更新缓存），高频调用时完全走内存计算，无数据库IO开销，单请求响应速度极快，不会给数据库带来额外压力
2. 不需要依赖数据库索引优化，内存足够的前提下性能稳定
   劣势：
3. 数据一致性差，仅能拿到加载时刻的快照数据，不适合要求数据实时性的场景，除非额外实现数据库变更同步更新内存缓存的逻辑
4. element表数据量过大时，会占用大量应用内存，甚至触发OOM；数据量超过10万级、单条text字段过长时，遍历性能也会明显下降
5. 需要额外实现全量数据的预加载、定时刷新、异常重试等逻辑，提升了代码复杂度

选择建议 #

满足以下所有条件时优先选择改造方案：

• element表数据量较小（建议10万条以内，全量加载后内存占用不超过服务总内存的10%）
• element表数据更新频率低，或业务允许分钟级的数据延迟
• 该方法调用频率极高（QPS超过100），原方案已导致数据库查询负载过高
  不满足以上条件时优先保留原方案，可通过给text字段加适配索引、增加数据库查询缓存等方式优化性能。

内容的提问来源于stack exchange，提问作者BlazekaMarko