ResultSet и выбор * производительность
Используя эти createElement функция, обеспеченная в этот ответ , который необходим из-за уязвимость IE с атрибутом имени на элементах, созданных обычно с document.createElement:
function postToURL(url, values) {
values = values || {};
var form = createElement("form", {action: url,
method: "POST",
style: "display: none"});
for (var property in values) {
if (values.hasOwnProperty(property)) {
var value = values[property];
if (value instanceof Array) {
for (var i = 0, l = value.length; i < l; i++) {
form.appendChild(createElement("input", {type: "hidden",
name: property,
value: value[i]}));
}
}
else {
form.appendChild(createElement("input", {type: "hidden",
name: property,
value: value}));
}
}
}
document.body.appendChild(form);
form.submit();
document.body.removeChild(form);
}
6 ответов
В зависимости от структуры таблицы, версии Oracle и задействованных индексов вполне возможно, что изменение набора выбранных столбцов существенно повысит производительность за счет изменения планов запросов в лучшую сторону. Для большинства запросов выигрыш в производительности может быть минимальным, но в целом рекомендуется явно указывать столбцы.
Самый простой случай, когда производительность будет улучшена, будет иметь место, когда у вас есть «покрытый индекс», который может использовать оптимизатор. . Если все столбцы, которые вы выбираете, и все столбцы, по которым выполняется фильтрация, являются частью единого индекса, этот индекс является покрываемым индексом для запроса. В этом случае Oracle может избежать чтения данных из таблицы и может просто прочитать индекс.
Есть и другие случаи, когда производительность также будет улучшена. Оптимизатор может выполнить исключение таблицы , если у вас есть запросы с промежуточными соединениями, которые не влияют на конечный результат. Если вы выбираете все столбцы, такая оптимизация невозможна. Если у вас есть таблицы со связанными строками, исключение столбцов также может устранить необходимость извлечения дополнительных блоков, в которых находятся удаленные столбцы. Если в таблице есть столбцы LONG и LOB, отказ от выбора этих столбцов также приведет к значительным улучшениям.
Наконец, удаление столбцов, как правило, сокращает объем пространства, которое потребуется Oracle для сортировки и хеширования результатов перед отправкой их по сети . И хотя ResultSet может лениво загружать данные в ОЗУ сервера приложений, вероятно, он не может лениво получать столбцы по сети. Если вы выберете все столбцы из таблицы, драйвер JDBC, скорее всего, должен будет получать по крайней мере одну полную строку за раз (более вероятно, что он получает 10 или 100 строк за один сетевой цикл туда и обратно). А поскольку драйвер не знает, когда данные будут получены, какие столбцы будут запрошены, вам придется отправить все данные по сети.
Я был бы удивлен, если бы перешел с "SELECT *" выбор «SELECT A, B, C» дал вам какое-либо значимое улучшение производительности, если только у вас не было огромного количества столбцов, которые вам не нужны.
Все это очень зависит от вашей базы данных, вашего драйвера и вашего приложения, и большинство обобщений будут бессмысленными.
Единственный надежный ответ, который вы получите из этого, - это сравнительный анализ - попробуйте «ВЫБРАТЬ *», попробуйте «ВЫБРАТЬ A, B, C» и посмотрите, стоит ли искать улучшения.
В средах, в которых я работал, как правило, SELECT * просто никогда не используется. Я считаю, что skaffman & aperkins, вероятно, правы в том, что прирост производительности небольшой. Это одна из тех вещей, где я, как разработчик базы данных, твердо придерживаюсь мнения, что вы всегда должны давать имена столбцам, которые вы извлекаете, но я полагаю, что для этого может не быть реальной основы.
Хммм ... Я думаю, с точки зрения ремонтопригодности можно утверждать, что присвоение имен столбцам, которые вы извлекаете, служит для некоторого самодокументирования вашего кода. SELECT * не дает другому разработчику столько информации, с которой нужно работать в дальнейшем. Я не уверен, оправдывают ли это и небольшое преимущество в производительности лишний набор текста.
Я никогда не замечал прироста производительности между одним и другим при переключении операторов - я вполне уверен, что Oracle в любом случае сначала захватывает содержимое всей строки, независимо от подстановочного знака или спецификации столбца. Перед этим необходимо проверить гораздо более важные факторы производительности (индексы, скорость жесткого диска и т. Д.).
В качестве практики кодирования я бы избегал " SELECT * ". Указание конкретных столбцов делает цель каждого запроса более очевидной. Это создает хороший самодокументирующийся код. Написание имен столбцов также помогает мне понять, что именно я планирую делать с запросом во время его написания.
Я с @skaffman и другими в этом вопросе - в лучшем случае незначительные достижения. Если вы думаете о том, как Oracle извлекает данные, и помните, что это блочный ввод-вывод, то, независимо от того, какие столбцы вы запрашиваете в своем клиенте, база данных в любом случае будет извлекать весь блок, в котором находится запись. Если ваш клиент всегда извлекает всю запись (например, выполняет SELECT * в SQL * Plus), может произойти прирост производительности, но в вашей ситуации, когда данные передаются только по вашему запросу, то, вероятно, немного.
«SELECT *» может быть злом для скомпилированных приложений. Если таблица изменится, ваш код может сломаться. Вот почему я бы не стал его использовать.
РЕДАКТИРОВАТЬ: Обдумывая все отличные ответы здесь:
- Джастин делает отличные замечания по поводу определенных ситуаций, в которых могут возникнуть значительные улучшения производительности. Чего я не вижу, так это того, чтобы кто-нибудь вообще не рекомендовал использовать "SELECT *". Если легко указать именно те столбцы, которые вам нужны, я бы исправил код для этого.
Я знаю, что в приложении, с которым я работал, при больших объемах данных (и больших размерах таблиц) изменение с select * на select x, y принесли нам небольшой прирост производительности. Однако я настоятельно рекомендую, как и скаффман, использовать инструмент профилирования, такой как встроенный профилировщик Oracle или внешний профилировщик, и делать большие наборы данных для нормализации шума (например, сетевой трафик, раскрутка жесткого диска, солнечные пятна и т. д.)