优化Slick生成的SQL查询

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (1)
  • 关注 (0)
  • 查看 (19)

我有一个非常简单的查询SQL可代表如下:

SELECT
  c.id,
  count(cp.product_id)
FROM cart c LEFT OUTER JOIN cart_product cp ON c.id = cp.cart_id
WHERE c.id = 3
GROUP BY c.id;

当我使用Slick DSL若要表示上述查询,请通过以下方法生成查询DSL:

Cart.joinLeft(CartProduct)
  .on { case (c, cp) => c.id === cp.cartId }
  .filter { case (c, cp) => c.id === 3 }
  .groupBy { case (c, cp) => c.id }
  .map { case (c, pr) => (c, pr.length)
}

情况如下:

SELECT
  x2.x3,
  count(1)
FROM (SELECT
        x4.x5  AS x3,
        x4.x6  AS x7,
        x8.x9  AS x10,
        x8.x11 AS x12,
        x8.x13 AS x14,
        x8.x15 AS x16
      FROM (SELECT
              x17."id"      AS x5,
              x17."user_id" AS x6
            FROM "cart" x17) x4 LEFT OUTER JOIN (SELECT
                                                   1                AS x9,
                                                   x18."id"         AS x11,
                                                   x18."cart_id"    AS x13,
                                                   x18."product_id" AS x15
                                                 FROM "cart_product" x18) x8 ON x4.x5 = x8.x13) x2
WHERE x2.x3 = 3
GROUP BY x2.x3;

我做错什么了?看到这样的嵌套查询是正常的吗?如果查询的复杂性增长如此之快,那么使用灵活的DSL又有什么意义呢?我可能会写土生土长的SQL不过我真的很喜欢Slick DSL...。优化的技术有哪些?Slick询问?

提问于
用户回答回答于

既然已经编写了使用PostgreSQL的文章,那么我就不用担心了,因为PostgreSQL以一个非常好的查询优化器而闻名。这样一个简单的转变是毫不费力的,几乎不需要额外的时间。唯一的事情是你等待,问题最终将被修复上游(在某个光滑的版本3.1),你不需要做任何事情。

P.S.:为什么不简单地使用这个查询?如果表上有一个外部约束,则应该返回完全相同的结果:

SELECT id, COUNT(*) FROM cart_product WHERE id=3

扫码关注云+社区