Как ускорить этот запрос?

Я обычно делаю эти шаги, пытаясь ускорить свои запросы

1. анализирую план выполнения.
2. попытайтесь создать (покрывающие) индексы, чтобы исключить сканирование таблиц.
3. попытайтесь создать (покрывающие) индексы, чтобы исключить сканирование индексов.

Что касается вашего запроса, вы не ошибетесь, создав индексы на

• A.event
• B.event
• B.state
• B.Hur

Вы можете добавлять индексы ко всему в предложениях WHERE и ORDER BY. Т.е. A.event, B.event и B.timestamp.

Запустите анализ объяснения запроса и прочтите его - если это не помогает - поместите выходные данные анализа объяснения на объяснение.depesz.com и проверьте, что это » говорит ".

Важно отметить, что порядок полей в индексе важен.

Индекс в некотором смысле является деревом поиска. Если вы проиндексируете (B.event, B.state), тогда дерево сгруппирует вместе все записи с полем сохранения «событие», а затем упорядочит их по полю «состояние».

Если бы вы затем запросили этот индекс для «b.state = x», от индекса будет мало толку; Индекс сначала упорядочивается по «событию».

В вашем примере:
- фильтровать A по его полю "событие"
- присоединитесь к A.event и B.event
- присоединитесь к B.state и C.id
- Присоединяйтесь к B.hur = D.id
- Порядок по B.event, B.timestamp

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

В вашем случае я ожидаю, что порядок B.event будет чрезвычайно важным. Просто потому, что это порядок результирующего вывода, И это поле, по которому вы фильтруете.

Затем вы присоединяете B.state к C.id. Таким образом, наличие и индексирование C.id - это хорошо, это ускоряет соединение. Но в равной степени наличие данных таблицы B в правильном порядке также может ускорить соединение.

Но наличие индекса на B.event и отдельного индекса на B.state может мало что дать. Индекс B.state становится почти бессмысленным, потому что мы используем индекс B.event. Если вы объедините два в один индекс (b.event, затем b.state), план выполнения может найти способ использовать часть индекса b.state.

Наконец, если вы поместите все поля в индекс, индекс действительно увеличивается, но запрос может никогда не обращаться к таблице. Информация находится в указателе. Время, необходимое для перехода от индекса к таблице для поиска «недостающих» полей, аналогично времени соединения. Таким образом, для повышения производительности чтения добавление дополнительных полей в индекс может иметь большое значение.

Я сейчас вспоминаю, но сводка такова:
Информация находится в указателе. Время, необходимое для перехода от индекса к таблице для поиска «отсутствующих» полей, аналогично времени соединения. Таким образом, для повышения производительности чтения добавление дополнительных полей в индекс может иметь большое значение.

Я сейчас вспоминаю, но сводка такова:
Информация находится в указателе. Время, необходимое для перехода от индекса к таблице для поиска «недостающих» полей, аналогично времени соединения. Таким образом, для повышения производительности чтения добавление дополнительных полей в индекс может иметь большое значение.

Я сейчас вспоминаю, но сводка такова:
- Обычно отдельные индексы по отдельным полям не используются вместе
- Для составных индексов порядок, в котором вы указываете поля, имеет значение
- Добавление «дополнительных» полей в индекс делает его больше, но также может ускорить запросы
- Порядок плана выполнения имеет большее значение, чем порядок вашего запроса
- Но по имеющимся у вас индексам можно определить порядок выполнения плана

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

Один из вариантов - перегрузить таблицы индексами, посмотреть на полученный план выполнения и удалить индексы, которые не нужны.

Но даже там есть предостережение применяется. Поскольку план выполнения зависит от данных (и статистики таблиц), очень важно иметь реальные данные в таблицах. Хотя в таблицах 10 или 100 строк, один план выполнения может быть самым быстрым. Но когда у вас есть миллионы строк, план выполнения может измениться, что принесет пользу другим индексам.

Я бы добавил индексы ко всему, что соединяется, в предложении where или в предложении order by.

В этом случае добавьте следующие индексы (при условии, что поля идентификатора являются первичными ключами и уже проиндексированы):

1. A.event
2. B.event
3. B .state
4. B.Hur
5. B.event, B.timestamp (объединенный индекс обоих полей)

Пятый индекс, являющийся комбинацией индексов, должен ускорить порядок.

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

SELECT B.event, B.system, COALESCE(C.surname) || ' ' || COALESCE(C.forename) AS name,    C.label, B.timestamp
FROM A            
INNER JOIN B ON A.event=B.event
INNER JOIN C ON B.state=C.id
LEFT OUTER JOIN D ON B.hur=D.id             
WHERE A.event = ANY(:visits) 
ORDER BY B.event, B.timestamp

Также ORDER BY сильно замедлит работу. Убедитесь, что они проиндексированы:

A.event
B.event
B.state
C.id
B.timestamp