При каких условиях ВЫБРАЛ бы PRIMARY KEY быть медленным?
Упорно искание некоторой производительности DB выходит в довольно типичном приложении EclipseLink/JPA.
Я вижу частые запросы, которые берут 25-100ms. Это простые запросы, просто выбрав все столбцы из таблицы, где ее первичный ключ равен значению. Они не должны быть медленными.
Я смотрю на время запроса в журнале пост-ГРЭС, с помощью log_min_duration_statement, таким образом, это должно устранить любую сеть или приложение наверху.
Этот запрос не является медленным, но он используется очень часто.
Почему был бы, выбирая * первичным ключом быть медленным? Действительно ли это характерно для пост-ГРЭС, или действительно ли это - универсальная проблема DB? Как я могу ускорить это? В целом? Для пост-ГРЭС?
Демонстрационный запрос от журнала pg:
2010-07-28 08:19:08 PDT - LOG: duration: 61.405 ms statement: EXECUTE <unnamed> [PREPARE: SELECT coded_ele
ment_key, code_system, code_system_label, description, label, code, concept_key, alternate_code_key FROM coded
_element WHERE (coded_element_key = $1)]
Таблица имеет приблизительно 3,5 миллиона строк.
Я также работал, ОБЪЯСНЯЮТ и ОБЪЯСНЯЮТ, АНАЛИЗИРУЮТ на этом запросе, его единственное выполнение индексного сканирования.
5 ответов
Select * усложняет работу вашей базы данных и, как правило, является плохой практикой. По поводу stackoverflow есть масса вопросов / ответов, говорящих об этом.
Вы пытались заменить * на имена полей?
Может быть, у вас какой-то конфликт блокировки? Какие блокировки вы используете при выполнении этих запросов?
select * почти всегда очень-очень плохая идея.
Если порядок полей изменится, это нарушит ваш код.Согласно комментариям, это не очень важно, учитывая используемую вами библиотеку абстракций.- Вы, вероятно, возвращаете из таблицы больше данных, чем вам действительно нужно. Выбор конкретных полей, которые вы хотите, может сэкономить время передачи.
25 мс - это нижняя граница, которую вы увидите практически для любого типа SQL-запроса - это всего два обращения к диску! Возможно, вы захотите найти способы уменьшить количество запусков запроса, а не пытаться оптимизировать запрос.
Строка необычно большая или содержит BLOBы и большие двоичные поля?
Это происходит непосредственно через консоль или этот запрос выполняется через какой-то API доступа к данным, например jdbc или ADO.NET? Вы упоминаете JPA, который похож на API доступа к данным. Для коротких запросов API доступа к данным становится большим процентом времени выполнения - создание команды, создание объектов для хранения строк и ячеек и т.д.
Что ж, я мало что знаю о postgres SQL, поэтому дам вам совет по MS SQL Server, который может быть применим.
В MS SQL Server используется концепция «кластерного индекса», который представляет собой физическую структуру данных на диске. Хорошо использовать в поле, где вы будете искать диапазон от значений до значений (в основном поля даты). В этом нет особого смысла, если вы ищете точное значение (например, поиск по первичному ключу). Однако иногда индекс первичного ключа случайно устанавливается как кластеризованный индекс. Это превращает поиск по индексу в сканирование таблицы.