Выбор запроса занимает 3 секунды, чтобы получить 330 записей. Нужна оптимизация

Question

У меня есть и обычный запрос выбора, выполнение которого занимает почти 3 секунды (Select * from users). В пользовательской таблице всего 310 записей.

Конфигурация моего производственного сервера

SQl Server Express Editon Конфигурация сервера: Pentium 4 HT, 3 ГГц, 2 ГБ ОЗУ

Column Nam  Type    NULL    COMMENTS
Column Nam              Type            NULL               
user_companyId          int         Not  Null
user_userId             int         Not Null Primary Column
user_FirstName          nvarchar(50)        Null                
user_lastName           nvarchar(60)        Null                
user_logon              nvarchar(50)        Null                
user_password           nvarchar(255)       Null                
user_emailid            nvarchar(255)       Null                
user_status             bit         Null                
user_Notification           bit         Null                
user_role               int         Null                
user_verifyActivation       nvarchar(255)       Null                
user_verifyEmail            nvarchar(255)       Null                
user_loginattempt           smallint        Null                
user_createdby          int         Null                
user_updatedby          int         Null                
user_createddate            datetime        Null                
user_updateddate            datetime        Null                
user_Department         nvarchar(1000)      Null                
user_Designation            nvarchar(1000)      Null        

Answer 1

Так как нет условия where, это не относится к индексам и т. Д., Sql выполнит полное сканирование таблицы и вернет все данные. Я бы смотрел на другие вещи, работающие на машине, или на SQL, который работал долго и использовал много виртуальных машин. Суть в том, что это не проблема SQL - это проблема компьютера.

Answer 2

Что-нибудь еще происходит на этой машине?

Даже если вы создали наихудшую структуру данных, SELECT * FROM Users не должен занимать 3 секунды для 310 записей. Либо есть больше (намного больше) записей внутри, либо есть проблемы вне SQL-сервера (некоторые другие процессы, блокирующие код или проблемы с оборудованием).

Answer 3

Есть несколько вещей, которые вы должны учитывать:

• Не используйте редакцию Express, вероятно, так называется. Используйте настоящую СУБД (и, конечно, это включает неэкспресс-сервер SQL).
• Использование "select * from" - это всегда плохая идея, если вам абсолютно не нужен каждый столбец. Измените его, чтобы получить только нужные вам столбцы.
• Используете ли вы предложение "where" или "order by". Если это так, вам нужно убедиться, что индексы настроены правильно (даже для 330 строк, поскольку таблицы всегда становятся больше, чем вы думаете).
• Используйте EXPLAIN или любой другой инструмент, предоставляемый Microsoft в качестве эквивалента. Он покажет вам, почему запрос выполняется медленно.
• Если ваша БД находится на другом компьютере, могут возникнуть проблемы с сетью (не обязательно проблемы, например, у вас могут быть фильтры пакетов с состоянием, которые замедляют соединения).
• Изучите системные загрузки ящиков, которые вы используете. Если есть другие процессы, использующие много ворчаний процессора или дискового ввода-вывода, они могут вызывать замедление.

Answer 4

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

Итак, есть только несколько других предметов, которые могут затопить это. Одним из них является размер строки. Какие колонки у вас есть? Если у вас есть тонны текстовых или графических столбцов, это может привести к задержке их возврата.

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

Answer 5

возможно ли снижение производительности в зависимости от размера столбца (длины данных в столбце).

в вашей таблице у вас есть последние 2 столбца с размером NVARCHAR (1000), он всегда заполнен таким количеством данных .. ??

Я не являюсь экспертом по SQL, но рассмотрим размер пакета, который он собирается вернуть для 310 записей с этими 2 столбцами и без них будет другим.

Я видел подобный пост здесь в стеке. Вы можете просто пройти через это

производительности в-SQL

Answer 6

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

Однако это не похоже на проблему с планом выполнения, поскольку запрос очень прост - на самом деле я вполне уверен, что запрос считается «тривиальным планом», т. Е. Существует только 1 возможный план.

Это оставляет проблемы с блокировкой или аппаратным обеспечением (является ли запрос медленным в вашей производственной базе данных, и всегда ли он медленным или время выполнения меняется?) Запрос попытается получить общую блокировку для всей таблицы - если кто-либо запись, тогда вы будете заблокированы от чтения, пока писатель не закончил. Вы можете проверить, не является ли это источником вашей проблемы, посмотрев на DMV: http://sqllearningsdmvdmf.blogspot.com/2009/03/top-10-resource-wait-times.html

Наконец, существуют ограничения на SQL Express с точки зрения использования процессора, использования памяти и т. Д. Какова нагрузка на ваш сервер? (операций в секунду)

Answer 7

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

Итак, рассмотрите возможность использования:

SELECT * FROM Users (NOLOCK);

Это будет означать, что вы не уважаете какие-либо блокировки, которые в настоящее время находятся на столе другими подключениями. Вы можете получить «грязное чтение», видя данные, которые еще не были зафиксированы, но это может быть полезно с точки зрения производительности.

Посмотрим правде в глаза - если вы рассмотрели последствия, то это должно быть хорошо ...

Rob

Answer 8

Если последовательно 3 секунды, проблема не в запросе или схеме, по любой причине, которая не будет явно иррациональной для дизайнера Я предполагаю, что это проблемы с оборудованием или сетью. Можно ли что-нибудь сделать с базой данных, которая не займет 3 секунды? О чем говорят SET STATISTICS IO ON и SET STATISTICS TIME ON? Могу поспорить, что там нет ничего, что поддерживает 3 секунды.

Answer 9

Лучше всего профилировать сервер, а также обращать внимание на то, какие блокировки происходят во время запроса.

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

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

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

Answer 10

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

Как насчет того, чтобы не использовать SELECT * FROM Users, но указать, какие поля вам действительно нужны из таблицы ??

SELECT user_companyId, user_userId,
       user_FirstName, user_lastName, user_logon
FROM Users

Как это работает ?? Вам все еще нужно 3 секунды для этого запроса, или это значительно быстрее?

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

Марк