Итерация по объекту результирующего набора JDBC

#java #database #jdbc

#java #База данных #jdbc

Вопрос:

В программе Java я использую сложный запрос (предложение select, которое имеет внутренние соединения и вложенные запросы). Я перебираю результирующий набор и записываю выходные данные в текстовый файл.

Вывод предложения Select может состоять из 400 000 записей. Вызовет ли это какие-либо проблемы, если в результирующем наборе будет так много записей? Имеет ли ResultSet какие-либо ограничения на запись / память?

1. Какую базу данных вы используете; поведение набора результатов зависит от базы данных / драйвера и используемого параллелизма набора результатов.

2. Вам нужны все 400 000 записей? Если нет, сузьте свой выбор в WHERE предложении -, чтобы выбрать только те записи, которые вам действительно нужны.

Ответ №1:

Сам результирующий набор не привязан. Однако ваш процесс JVM и сетевые возможности имеют ограничения. Если вам нужно обработать много записей из одного запроса, попробуйте поиграть с доступными параметрами результирующего набора:

 Statement stmt = con.createStatement("select * from dual", ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
stmt.setFetchSize(1000);

В зависимости от вашей базы данных и / или поставщика драйверов они могут помочь вам быстрее обрабатывать запросы с меньшим объемом памяти.

1. установка большего размера выборки будет быстрее, но с БОЛЬШИМ объемом памяти. Это просто компромисс между циклами памяти и БД

2. @AdrianShum ну, для некоторых драйверов это на самом деле может привести к разделению запрошенного набора данных на более мелкие части и отправке вам их по одному вместо того, чтобы отправлять весь набор результатов сразу. Но я согласен с вами, размер выборки следует выбирать с умом.

3. ну, я ни в коем случае не могу себе представить, что установка большего размера выборки приведет к тому, что драйвер разделит данные на более мелкие части. Вся цель размера выборки состоит в том, чтобы сообщить драйверу подготовить буфер для извлечения для указанного количества записей, это не будет иметь смысла, если окажется, что он меньше. И это просто здравый смысл: если вы получаете больше вещей одновременно, вы уменьшаете количество обходов, но требуете больше памяти. Нет никакого способа, чтобы уменьшение размера уменьшало количество обходов.

4. Конечно, если вы сравните размер выборки огромного размера с размером выборки разумно меньшего размера, меньший размер может потребовать меньше времени, но это просто потому, что накладные расходы, вызванные этим огромным буфером, вызывают медлительность. И установка значения 1000 as в вашем примере редко является разумным числом, если вы не собираетесь иметь дело с чрезвычайно огромным количеством записей. Обычно диапазон для «большого» размера выборки составляет около 20-100

5. @AdrianShum не зависит ли размер выборки по умолчанию полностью от реализации драйвера? На самом деле я не готов спорить на эту тему, пока мы все еще не знаем поставщика базы данных.