#sql #tsql
#sql #tsql
Вопрос:
Я написал этот запрос, чтобы получить всю информацию, необходимую для моей задачи. Но из-за моего недостатка знаний в SQL запрос не так хорош. Запрос приводит к очень длительному времени выполнения. База данных, которая используется для выполнения запроса, содержит более миллиона строк только за один этот год, поэтому я очень надеюсь, что ее можно оптимизировать.
CREATE VIEW vNew_Test_View AS
SELECT a.point_id, a.lab_station_id, a.point_name, b.timestamp, c.timezone, b.value,
LAG(b.value,1,0) OVER(PARTITION BY b.point_id ORDER BY timestamp) AS val_prev
FROM PointList a,
PointData b,
Lab_Timezone c
WHERE a.point_id = b.point_id
AND a.lab_station_id = c.lab_station_id
AND b.timestamp > '01/01/2020'
Оптимально я хотел бы получить несколько указаний на то, что нужно улучшить, возможно, как или где искать.
База данных настроена таким образом, что мне нужен lab_station_id, чтобы знать, какой часовой пояс.
Цель заключается в следующем:
Комментарии:
1. Как вы ожидаете, что люди смогут вам помочь, если вы не говорите нам, что именно вы пытаетесь сделать? Я понятия не имею, что должен делать ваш запрос.
2. Почему этот устаревший стиль соединения через запятую все еще используется? Пожалуйста, изучите правильный синтаксис соединения
3. Привет, для справки на будущее, многим из нас действительно сложно следить за снимками экрана ваших данных. У вас ГОРАЗДО больше шансов получить хороший ответ, если вы скопируете / вставите дату в вопрос, а затем используете инструмент форматирования кода, чтобы сохранить разрывы строк и интервалы.
4. Необходимо ли предоставлять функцию ЗАДЕРЖКИ в вашем выводе?
Ответ №1:
Всякий раз, когда у вас возникают проблемы с производительностью, вам нужно обратиться к плану объяснения.
В этой статье объясняется, как вы можете это сделать: https://learn.microsoft.com/en-us/sql/relational-databases/performance/display-an-actual-execution-plan?view=sql-server-ver15
В общем, вы хотите иметь индексы для столбцов, к которым вы присоединяетесь, и для тех, которые вы фильтруете, чтобы повысить производительность. Если вы можете предложить больше информации о плане explain, я мог бы посоветовать дальше.
Ответ №2:
Первое улучшение, которое я бы сделал, — это избавиться от этих старых janky a,b where
joins. Этот синтаксис устарел уже 25 лет. Вместо этого используйте реальный a inner join b on
синтаксис.
Следующее, что я бы сделал, это использовал лучший литерал даты. Для значений только для даты (без компонента времени) лучшим вариантом является неотделенный формат ISO8601. Так 01/01/2020
становится 20200101
.
В итоге мы получаем следующее:
SELECT a.point_id, a.lab_station_id, a.point_name, b.timestamp, c.timezone, b.value,
LAG(b.value,1,0) OVER(PARTITION BY b.point_id ORDER BY timestamp) AS val_prev
FROM PointList a
INNER JOIN PointList b ON b.point_id = a.point_id
INNER JOIN PointList c ON c.lab_station_id = a.lab_station_id
WHERE b.timestamp > '20200101'
Однако это мало что даст, если вообще что-то даст в течение длительного времени выполнения, и, вероятно, вы мало что можете сделать в одном SQL-запросе, который поможет; то есть я не вижу здесь никаких очевидных проблем с производительностью. Вместо этого, чтобы получить какое-либо значимое улучшение, вы должны посмотреть, какие индексы определены в этих таблицах.