Slick中复合键批量更新表的栈溢出问题及替代方案咨询

你的问题根源在于：当soldCoffees数量较多时，用reduceLeftOption拼接大量OR条件会生成嵌套极深的AST，Slick在将AST转换为SQL语句时直接把栈撑爆了。下面是几种更高效、安全的实现方式：

1. 使用元组IN子句（推荐） #

Slick支持将复合字段（比如from+kind）作为元组，利用SQL的IN子句进行批量过滤。这种方式生成的AST是扁平的，不会出现嵌套过深的问题，而且完全保留Slick的类型安全。

修改后的代码：

def markAsSold(soldCoffees: Seq[Coffee]): Future[Int] = {
  val coffeeIdentifiers = soldCoffees.map(sc => (sc.from, sc.kind))
  val cmd = coffees
    .filter(coffee => (coffee.from, coffee.kind) inSet coffeeIdentifiers)
    .map(_.sold)
    .update(true)
  // 原代码用stream返回的是流，若要获取总更新行数，用db.run(cmd)更合适
  db.run(cmd)
}

如果你的Slick版本支持inSetBind（更适合大集合，自动处理参数绑定），可以替换成：

.filter(coffee => (coffee.from, coffee.kind) inSetBind coffeeIdentifiers)

这个方案的优势：

• 生成的SQL更简洁：WHERE (from, kind) IN ((?, ?), (?, ?), ...)
• AST结构扁平，彻底避免栈溢出
• 完全基于Slick API，无需写原生SQL或修改表结构

2. 分批次处理 #

如果soldCoffees的数量特别大（比如上万条），即使使用IN子句也可能触发数据库的参数数量限制，这时候可以分批次更新：

import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global

def markAsSold(soldCoffees: Seq[Coffee], batchSize: Int = 100): Future[Int] = {
  val batches = soldCoffees.grouped(batchSize)
  val batchFutures = batches.map { batch =>
    val identifiers = batch.map(sc => (sc.from, sc.kind))
    coffees
      .filter(coffee => (coffee.from, coffee.kind) inSetBind identifiers)
      .map(_.sold)
      .update(true)
      .map(_.toInt)
  }
  Future.sequence(batchFutures).map(_.sum)
}

这个方案把大集合拆成小批次，每个批次的条件数量可控，既避免栈溢出，也不会触发数据库的参数上限。

3. 你提到的备选方案（补充说明） #

• 原生SQL：确实可以解决问题，但会失去Slick的类型安全，需要手动处理参数绑定。示例：

  def markAsSold(soldCoffees: Seq[Coffee]): Future[Int] = {
    val placeholders = soldCoffees.map(_ => "(?, ?)").mkString(",")
    val params = soldCoffees.flatMap(sc => List(sc.from, sc.kind))
    db.run(sqlu"""UPDATE coffees SET sold = true WHERE (from, kind) IN ($placeholders)""".bind(params: _*))
  }
  

• 新增拼接列：比如新增from_kind列（值为from + "_" + kind），然后用单一字段的IN过滤。但需要修改表结构，还要处理数据同步（比如插入/更新时自动维护这个字段），适合长期需要频繁按这两个字段过滤的场景，但改动成本较高。

内容的提问来源于stack exchange，提问作者Michał Chmielarz