Есть ли возможность для обхода ограничения привязки параметров PostgreSQL 32760?

Question

В моем хранилище есть метод JPA, который пытается найти объекты с предложением where. Проблема в том, что у меня огромный набор данных, и когда я пытаюсь отправить более 32 тыс. Элементов в предложении списка, я получаю сообщение об ошибке. Я обнаружил, что это ограничение драйвера PostgreSQL, но я не могу найти обходной путь.

Я попытался Pageable запрос, но трудно отправить только 30 КБ для 8 миллионов записей. Есть ли возможность отправить более 30 тыс. Объектов в моем предложении в списке where?

List<Object> findAllByIdIn(List<Long> ids)

Answer 1

Нет, вы не хотите делать это, особенно если вы планируете отправить 8 миллионов идентификаторов. Обход оператора IN или ограничения параметра связывания неэффективен. Учтите следующее:

1. Тысячи параметров связывания приведут к мегабайту SQL. Отправка текста SQL в базу данных займет значительное время. Фактически, для чтения текста SQL может потребоваться больше времени, чем для выполнения запроса в соответствии с ответом Тома на вопрос «Ограничение и преобразование очень длинный список IN: ГДЕ x IN (,,, ...)» .

2. Синтаксический анализ SQL будет неэффективным. Не только мегабайты текста SQL требуют времени для чтения, но и с увеличением числа параметров привязки каждый запрос обычно будет иметь различное количество используемых связанных параметров. Это отдельное количество связанных параметров приведет к тому, что каждый запрос будет проанализирован и спланирован отдельно (см. в этой статье, которая объясняет это ).

3. В операторе SQL существует жесткое ограничение связанных параметров. Вы только что обнаружили это, 32760.

Для таких типов запросов обычно лучше создать временных таблиц . Создайте новую временную таблицу перед вашим запросом, вставьте в нее все идентификаторы и объедините ее с таблицей сущностей. Это объединение будет эквивалентно условию IN, за исключением того, что текст SQL будет коротким.

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