Основная проблема, связанная с производительностью, заключается в том, что анализ оператора SQL (в том числе проверка существования таблиц и столбцов) и создание оптимизированного плана выполнения обходятся дорого.Если кэшированный план выполнения можно использовать повторно, выполнение обычно выполняется быстрее.
Таким образом, вопросы также можно перефразировать следующим образом: Нужно ли использовать PreparedStatement (и CallableStatement), чтобыповторно использовать кэшированный план выполнения?
Ответ зависит от вашей системы баз данных.
В некоторых системах, таких как Oracle (с настройками по умолчанию и рекомендуемыми настройками), требуется PreparedStatement для повторного использования плана выполнения,В противном случае он будет выполнять повторный анализ всего запроса (иначе как hard parse ) всякий раз, когда изменяется одно значение в запросе.Еще хуже, поскольку новый запрос и его план будут добавлены в кеш, из кеша нужно будет удалить что-то еще.Таким образом, это может также негативно повлиять на других клиентов базы данных, используя подготовленные операторы.
Другие системы, такие как SQL Server, не полностью полагаются на подготовленные запросы.Для неподготовленных запросов они будут угадывать, какие значения должны быть преобразованы в параметры, будут создавать план выполнения и кэшировать его.Если другой неподготовленный запрос соответствует ранее параметризованному запросу, план можно использовать повторно.Этот подход очень полезен, когда ленивые программисты не всегда используют подготовленные запросы.Но он не достигает полной скорости подготовленных запросов, поскольку параметризация и сопоставление занимают больше времени и поскольку сгенерированный план выполнения может иметь слишком много параметров, быть слишком общим и, следовательно, неоптимальным.
И вам не нужноуслышать, но я все равно скажу: подготовленные операторы - лучший рецепт против атак с использованием SQL-инъекций.