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

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

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

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

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

Это даст вам информацию о чтениях, записях, затраченном времени и т. Д.

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

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

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

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

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

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

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

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

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

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

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

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