Почему PreparedStatement намного быстрее, чем Statement?

Question

Почему PreparedStatement намного быстрее, чем Statement?

1

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

БД была Oracle, содержащая таблицу из 22 полей. Эта таблица должна была заполняться постепенно с 1 млн записей до 100 млн записей.

Для заполнения таблицы 1 милем я генерировал случайные тестовые данные и использовал выражение Java для вставки его в БД, и это заняло около 17 и 16 секунд минут. После этого я быстро понял, что для заполнения таблицы столов на 100 миллионов займет время, поэтому я попробовал ее с помощью PreparedStatement, потому что знал, что это немного быстрее... но разница была настолько огромной, 1 мин и 24 секунды, что я начал искать в Интернете причину этого и выяснять некоторые причины, но ничего, что, на мой взгляд, должно иметь такое влияние.

это то, что я нашел, что может объяснить эту разницу: LINK

PreparedStatement получает предварительную компиляцию. В базе данных и в ней также кэшируется план доступа, который позволяет базе данных выполнять параметрический запрос, написанный с использованием подготовленного оператора, намного быстрее, чем обычный запрос, потому что у него меньше работы. Вы всегда должны пытаться использовать PreparedStatement в коде JDBC для уменьшения нагрузки на базу данных. Чтобы получить выгоду от производительности, стоит отметить использование только параметризованной версии SQL-запроса, а не конкатенации строк.

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

aurelius 10 дек. 2014, в 19:11

Источник

3

Прочитайте о жестком и мягком разборе Oracle и SGA. Существует много циклов обработки, используемых для неподготовленной / литеральной версии вставки для жесткого анализа.
OldProgrammer 10 дек. 2014, в 17:54
0

Я рекомендую вам отслеживать программу до и после внесения таких изменений. Убедитесь, что тест справедлив. Затем профилируйте полученные файлы трассировки. Результаты часто бывают удивительными.
Jeff Holt 01 июнь 2016, в 21:20

Теги:

java

oracle

jdbc

1 ответ

Ещё вопросы

Прочитайте о жестком и мягком разборе Oracle и SGA. Существует много циклов обработки, используемых для неподготовленной / литеральной версии вставки для жесткого анализа.
Я рекомендую вам отслеживать программу до и после внесения таких изменений. Убедитесь, что тест справедлив. Затем профилируйте полученные файлы трассировки. Результаты часто бывают удивительными.

Elliott Frisch · Accepted Answer · 2014-12-10T16-26-00.000Z

Возможно, Oracle может кэшировать план запроса в кэше операторов; в руководстве разработчика Oracle Database Database JDBC Неявное кэширование выписки,

Когда вы включаете неявное кэширование Statement, JDBC автоматически кэширует подготовленный или вызываемый оператор, когда вы вызываете метод close этого объекта-оператора. Готовые и вызываемые операторы кэшируются и извлекаются с использованием стандартных объектов объекта соединения и методов объекта-оператора.

Обычные заявления неявно кэшируются, потому что неявное кэширование Statement использует строку SQL в качестве ключа, а простые инструкции создаются без строки SQL. Следовательно, неявное кэширование Statement применяется только к OraclePreparedStatement и OracleCallableStatement, которые создаются с помощью строки SQL.

Хорошо, давайте предположим, что план запроса кэшируется, но у меня все еще есть 22 случайных поля на вставку, это больше, чем половина всего оператора вставки ...
Но вы не отправляете весь запрос; просто идентификатор запроса (и ваши поля). Не запрос плюс поля. Затем добавьте кеширование.
Я не вижу, где закрывается PreparedStatement. Я, конечно, понимаю, как неявное кэширование может быть очень полезным, если кто-то закрывает и снова открывает Prepared Statement с тем же SQL-кодом, но образец PreparedStatement в этом вопросе выглядит для меня как стандартная реализация подготовленных операторов (отправьте оператор один раз , затем отправьте параметры для каждого запроса). Я что-то здесь пропустил?
@aurelianus План запроса - это не текст запроса, он примерно аналогичен байт-коду запроса. Повторное использование плана избавляет от необходимости компилировать миллион строк кода.