Как отладить запрос базы данных для производительности

Question

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

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

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

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

Answer 1

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

Также см: SQL Performance Tips

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Соединения и таймаут не являются проблемами, с которыми я обычно сталкиваюсь.

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

Answer 5

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

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

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

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

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

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

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

Answer 6

This is a good article о том, как оптимизировать ваши заявления SQL и вещи, которые вы примите во внимание:

Answer 7

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

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

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

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