JOOQ несколько объединений с одной и той же производительностью таблицы

Ожидается ли это?

Да, это.

Хотя на первый взгляд кажется, что перемещение по одному и тому же пути внешнего ключа снова и снова бессмысленно, и соединения можно устранить, на самом деле это невозможно. Каждый сегмент пути «ко-многим» может создавать декартово произведение с предыдущими сегментами, точно так же, как это может сделать любое обычное явное соединение «ко-многим». Следовательно, из-за небольшой вероятности того, что такое декартово произведение будет желательным, jOOQ не может предотвратить это без изменения логики запроса, поэтому, если вы скажете jOOQ повторно присоединиться к одной и той же таблице много раз (даже если вы не собираетесь этого делать) , то jOOQ должен будет повторно присоединиться к одной и той же таблице много раз, чтобы реализовать потенциально желаемую логику запроса.

Обратите внимание, что переходы обратно к родительскому элементу фактически исключаются, поскольку их удаление не меняет семантику запроса в вашем случае, поскольку родительский столбец не проецируется:

• https://github.com/jOOQ/jOOQ/issues/14992
• https://blog.jooq.org/a-hidden-benefit-of-implicit-joins-join-elimination/

Создают ли несколько соединений в одной таблице проблемы с производительностью?

Конечно! Это не только приводит к проблемам с производительностью, но и дает неправильные результаты. Похоже, вы включили Settings.renderImplicitJoinToManyType просто для того, чтобы «заставить его работать», не задумываясь о последствиях. Но последствия именно такие, как я сказал. Ваше предложение WHERE теперь дает декартово произведение, чего я сомневаюсь, что вы этого хотите и не ожидаете.

В разделе руководства о неявных соединениях путей ко-многим об этом ясно сказано

Случайные дубликаты объектов не являются основной проблемой, которую могут вызвать такие неявные объединения путей ко-многим. Основная проблема заключается в том, что неявный путь ко многим, помещенный в предложение SELECT или предложение WHERE (и другие предложения), сможет генерировать строки, тогда как на самом деле SELECT только преобразует строки (например, Stream.map()) и WHERE только фильтрует строки (например, Stream.filter() ). Было бы слишком SQL-унидиоматично и запутанно, если бы эти предложения могли эффективно создавать строки.

В вашем конкретном случае вы, вероятно, захотите переместить предикат в подзапрос EXISTS, используя корреляцию пути соединения , например.

ctx
  .select(ENTITY.ID)
  .from(ENTITY)
  .where(exists(
    selectOne()
    .from(ENTITY.subEntity()
      ...
      .entity().NAME.eq("a")
    )
  ))
.getSQL()

Для этого не требуется включать вышеуказанное спорное Settings.renderImplicitJoinToManyType. У вас все еще будет странный путь и ненужные соединения, но, по крайней мере, теперь вы не получите никаких декартовых произведений.

Избавление от циклов

Вы лучше всех знаете свою собственную семантику перевода RQL в jOOQ. Если вы знаете, что можете удалить эти циклы, то лучше всего сделайте это самостоятельно. Я надеюсь, что приведенный выше ответ прояснил, почему jOOQ не может сделать это за вас автоматически.