Как отладить запрос к базе данных для производительности - PullRequest
5 голосов
/ 02 июля 2010

Я абсолютно новичок в базах данных и SQL-запросах.

Q1. Каковы общие проблемы одного вообще сталкиваются в запросах к базе? Вероятно, чрезвычайно большие запросы, проблемы с производительностью, ошибки времени ожидания и подключения, ошибки импорта и экспорта и восстановления

Q2. Какой подход и инструменты нужно знать об этом при отладке SQL производительность запроса?

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

Ответы [ 7 ]

5 голосов
/ 02 июля 2010

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

Я не уверен, какую базу данных вы используете, но с SQL ServerВ перспективе вы бы хорошо научились использовать SQL Profiler.Вы также можете просмотреть план выполнения запроса через SQL Management Studio, это укажет, где могут быть проблемы с производительностью в вашем запросе.

5 голосов
/ 02 июля 2010

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

Также см .: Советы по производительности SQL

2 голосов
/ 25 декабря 2016

Я отладил с помощью показанного метода здесь , и один из методов сработал для меня.

Я проверил, выполняется ли запрос дольше всего и пришелЗнайте, что некоторые запросы зависли и работали более 3-4 часов.Чтобы узнать, сколько времени выполняется запрос, выполните следующую команду:

SELECT max(now() - xact_start) FROM pg_stat_activity
                               WHERE state IN ('idle in transaction', 'active');

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

1 голос
/ 02 июля 2010

Это хорошая статья о том, как оптимизировать ваши операторы SQL и что вы учитываете:

1 голос
/ 02 июля 2010

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

Проблемы в запросах к базе данных -

Неправильные результаты - запрос на самом деле не делает то, что вы хотите

Производительность - время ожидания запроса слишком велико. Это может быть вызвано многими причинами, но есть несколько общих причин: плохой дизайн базы данных (например, не используйте таблицы EAV), использование неэффективных технических запросов, таких как коррелированные подзапросы, циклический просмотр записей по одному, отсутствие правильной индексации, статистика устаревшие запросы, которые не являются sargeable и, конечно, проблемы с оборудованием и сетью.

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

Безопасность - база данных не защищает должным образом свои данные (шифрование личных данных, кодирование во избежание атак с использованием инъекций, ограничение прав на выполнение действий с данными и т. Д.)

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

1 голос
/ 02 июля 2010

Самым важным для отладки SQL-запросов является SQL Server Profiler. http://msdn.microsoft.com/en-us/library/ms187929.aspx

Это даст вам чтение, запись, затраченное время и т. Д.

Планы выполнения также очень полезны и покажут вам, выполнял ли он сканирование вместо поиска или наоборот. Посмотрите на это также http://msdn.microsoft.com/en-us/library/ms178071.aspx

0 голосов
/ 02 июля 2010

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

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

Соединения и время ожидания - это не те проблемы, с которыми я обычно сталкивался.

Что касается запросов - используйте планы объяснения, которые позволяют вам определить, как ядро ​​базы данных будет выполнять ваши запросы.(Это определит, как будут выполняться объединения и в каком порядке, и количество ваших объединений - если вы сможете уменьшить количество связей во многих объединениях, ваш запрос будет выполняться быстрее)

...