Большой набор данных SQL запрос с использованием Java

Question

У меня есть следующая конфигурация:

• SQL Server 2008
• Java как технология бэкэнда - Spring + Hibernate

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

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

Спасибо.

Answer 1

Я бы запустил Profiler, чтобы найти точный генерируемый запрос.ORM могут создавать неоптимальные запросы.Как только вы знаете запрос, вы можете запустить его в SSMS и увидеть план выполнения.Это даст вам понять, где у вас проблемы с производительностью.

Несколько факторов, которые могут вызвать проблемы с производительностью:

• Отсутствие правильной индексации (внешние ключи должны быть проиндексированы, если у вас есть объединения, а также критерии в предложении where)
• Недостаточная проходимость в предложении where, что вынуждает запрос не использовать существующие индексы
• Возвращает больше столбцов, чем необходимо
• Коррелированные подзапросы и скалярные функции, которые вызывают row-by-agonzing-rowоперации
• Возврат слишком большого количества данных (кто-нибудь действительно будет просматривать возвращенный миллион записей? Вам нужно только вернуть сумму, отображаемую на странице, а не весь возможный набор записей)
• Блокировка и блокировка

Есть еще кое-что (ведь на эту тему написаны целые очень длинные книги), но этого должно быть достаточно, чтобы вы начали искать, где искать.

Answer 2

Первое, что я делаю в этом случае, это изолирую, является ли это объемом данных, которые я возвращаю, это проблема или нет (проблема ввода / вывода). Простой ненаучный способ сделать это - изменить свой запрос, просто вернув счетчик:

select count(*) --just return a count, no data!
from MyTable
inner join MyOtherTable on ...
where ...

Если это выполняется очень быстро, это говорит о том, что ваши индексы в порядке (при условии, что в предложении WHERE нет подвыборов). Если нет, то вам нужно поработать с индексами , предложением WHERE или самой конструкцией запроса (выполняются JOINs и т. Д.).

Как только это удовлетворительно, добавьте обратно в ваше предложение SELECT. Если он медленный, вам нужно взглянуть на ваш шаблон доступа к данным:

• Можете ли вы вернуть меньше столбцов?
• Можете ли вы вернуть меньше строк одновременно?
• Можно ли выполнять кэширование на уровне приложений?
• Является ли этот запрос кандидатом для секционированных / материализованных представлений (если ваша база данных поддерживает их)?

Answer 3

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

• http://odetocode.com/articles/70.aspx
• http://www.simple -talk.com / sql / learn-sql-server /sql-server-index-basics /
• http://www.petri.co.il/introduction-to-sql-server-indexes.htm

Answer 4

Независимо от конкретной БД, я бы сделал следующее:

1. запустите анализ объяснения
2. , чтобы убедиться, что у вас есть индекс для столбцов, которые являются частью предложения where
3. Если с индексами все в порядке, очень вероятно, что вы извлекаете много записей с диска, что очень медленно: если вы действительно не можете уточнить свой запрос, чтобы получить меньше записей, рассмотрите возможность кластеризации таблицы, чтобыулучшить локальность диска ваших записей.

Answer 5

Вы должны предоставить некоторые индексы для тех столбцов, которые вы часто используете для ограничения результата.Другая вещь - это нумерация результирующего набора.