Фильтрация просмотра 20 тысяч строк занимает 30 минут - PullRequest
Новая
       18

Фильтрация просмотра 20 тысяч строк занимает 30 минут

0 голосов
/ 13 июня 2019

Моя проблема в том, что у меня есть представление, которое возвращает 20 000 строк данных за определенный день 

select * from view
where date = X

, но затем, когда я добавляю условие where для периметра, мне нужно 

select * from view 
where date = X and perimeter in ( 'A' , 'B' , 'C', 'D' )

результат на 10.000 строк больше или меньше, но для получения результата требуется до 30 минут.

Представление довольно сложное с десятками объединений и агрегатов и т. д.

как я могу это исправить?

Спасибо за вашу помощь, и если у вас есть какие-либо вопросы, спросите меня:)

** ОБНОВЛЕНИЕ: спасибо за ваши ответы.Настоящий запрос довольно сложный.Это всего лишь пример, чтобы объяснить мою проблему.План выполнения довольно длинный и бесполезный, так как у меня есть точный (100%) один и тот же план выполнения (оценочный и реальный), использую ли я фильтр по столбцу периметра или нет.но время позади этого идет от 30 секунд, когда я только фильтрую дату до 30 минут, когда я добавляю фильтр периметра.поэтому это должно означать, что план выполнения в любом случае неправильнстатистика обычно обновляется по этим таблицам.нет индекса по этому столбцу в таблице, где я его ищу.необходимо добавить один для просмотра?Столбец, по которому мы фильтруем, получается благодаря левому соединению в представлении **

1 Ответ

0 голосов
/ 13 июня 2019

Сначала спросите себя:

Нормально ли брать такое время?

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

Если это не ваш случай, тогда:

  • Нужны ли все столбцы? - почему SELECT *, выбирая только необходимые столбцы, может иногда оптимизировать выполнение представления
  • Нужна ли вся логика, используемая в представлении? - если представление настолько сложное, подумайте, можно ли получить только нужные вам операторы (например, создать отдельное представление с меньшим количеством логики, меньшим количеством источников данных, меньшим количеством столбцов)
  • Использует ли запрос лучшие индексы - это огромная тема , но вы выполняете filtering, так что может быть возможно оптимизировать запрос, используя соответствующий индекс или даже отфильтрованный индекс?
  • Можно ли отфильтровать данные заранее? - иногда вы можете создать встроенную табличную функцию , чтобы выполнить фильтрацию заранее (функция - это, в основном, представление с параметрами) - представьте, что в эту функцию передан параметр 'X', который будет передан другой функции рефери в представлении, возвращающем теперь только 5% сгенерированных ранее строк - так что, возможно, некоторые значения в ваших предложениях WHERE могут быть переданы как paramateres);
  • Нужно ли материализовать это представление? - это последнее средство, но вы можете создать индекс для представления , чтобы материализовать его как обычную таблицу и оптимизировать производительность, далее (обратите внимание, что не каждое представление может быть проиндексировано)

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

...